Skip to content
\n

Solution 2: The \"Persistence Hack\" (Complex)
\nIf you are deeply committed to using ArbitraryCallbackData (e.g., passing whole objects), you would need to force the bot to check Redis when it encounters a \"cache miss\" (an unknown UUID).

\n

Standard PTB does not support this out of the box. You would need to subclass CallbackDataCache or monkey-patch it.

\n

The Logic:

\n

Create a custom RedisCallbackDataCache.

\n

Override the process_callback_query method.

\n

If the UUID is not found in local RAM, attempt to fetch it from Redis before raising InvalidCallbackData.

","upvoteCount":2,"url":"https://github.com/python-telegram-bot/python-telegram-bot/discussions/5064#discussioncomment-15245234"}}}
Discussion options

You must be logged in to vote

The Problem: Memory vs. Persistence
PTB's ArbitraryCallbackData system is designed primarily for single-instance bots.

Local Cache: It relies on an in-memory CallbackDataCache (RAM) to map the UUIDs (sent to Telegram) back to your Python objects.

Startup Only: The persistence layer (BasePersistence) loads callback data only on bot startup. It does not check the persistence layer dynamically when it receives an unknown UUID.

This is why Instance B cannot "see" the button created by Instance A—it loaded its cache at startup, and Instance A's new button was never synced to Instance B's RAM.

The Solutions
There are two ways to solve this. The first is the "Architecturally Correct" way for dis…

Replies: 1 comment

Comment options

You must be logged in to vote
0 replies
Answer selected by makisukurisu
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
2 participants