Discussion: follow-up questions for PR #22

[juanjoGonDev]

Hi @achetronic,

As requested in #22 discussion, opening this issue to continue the questions and follow-up outside the PR thread.

Context

PR #22 is focused on Telegram thread-aware routing + admin test delivery improvements.

[achetronic]

Hello @juanjoGonDev Thanks for opening the issue 🚀

I would like to discuss about the problematic you found with Telegram client. What is wrong with the client exactly?

[juanjoGonDev]

Hello @juanjoGonDev Thanks for opening the issue 🚀

I would like to discuss about the problematic you found with Telegram client. What is wrong with the client exactly?

I found another bug related to secrets.

If the Telegram bot token is configured using a secret placeholder (for example ${MY_TELEGRAM_TOKEN}), Magec resolves it correctly and the bot works. However, if that secret is later deleted from the Secrets section, the Telegram bot can still continue working, and the Telegram test action can also still work.

In practice, Magec does not detect that the secret has been removed until the process is restarted. The resolved secret value seems to remain alive in runtime memory, so deleting the secret does not immediately invalidate configurations that were already using it.

So this does not look Telegram-specific. Telegram is just where I noticed it first, but it probably affects any config field that relies on ${SECRET_KEY} expansion.

[achetronic]

So, to narrow down, de bug discussed here is about restaring the agents when a secret is deleted tu be completely sure the secret is truly invalidated. Ok, I understand 🙂

So the PR seems to cover not only this issue but several ones. Would it be possible to break it down in different PRs to fix one problem/feature at a time?

I would like to discuss the rest of the PRs separatedly to keep the discussion clean. I think the solution for the secrets issue is just to detect which agents are using placeholders when the placeholder is invalidated and just disable the agent. Because of this, enabling the agent will not have credentials in memory. What do you think about this fix?

[juanjoGonDev]

So, to narrow down, de bug discussed here is about restaring the agents when a secret is deleted tu be completely sure the secret is truly invalidated. Ok, I understand 🙂

So the PR seems to cover not only this issue but several ones. Would it be possible to break it down in different PRs to fix one problem/feature at a time?

I would like to discuss the rest of the PRs separatedly to keep the discussion clean. I think the solution for the secrets issue is just to detect which agents are using placeholders when the placeholder is invalidated and just disable the agent. Because of this, enabling the agent will not have credentials in memory. What do you think about this fix?

I think I explained it poorly.

The secrets bug is not something PR #22 is trying to fix. I only mentioned it as an additional out-of-scope finding discovered during manual validation.

The main goal of PR #22 is Telegram thread-aware routing, so replies stay in the originating topic/thread. The PR also includes some related Telegram admin/testing improvements, but it does not implement a fix for the secret invalidation lifecycle problem.

The only connection is that the new Telegram test action supports ${ENV_VAR} placeholders to match runtime behavior, and that made the existing secret issue easier to notice. But the PR does not try to solve that issue.

If you prefer, I can split the current PR into smaller ones and keep the secrets problem fully separate from the thread-routing feature discussion.

[achetronic]

I would like keep the PR inside de scope then. I saw some pictures that are not present now (at least I can not find them anymore) with some UI changes. Of course we need them, but I would like in the first PR to have it at the same level as the other clients and then adding some extra changes.

I'm saying this because in the other clients, if you see the UI, you can select the number of messages passed from a thread to the agent. This is because in most chats, the thread is completely separated from the main conversation, so talking into a thread, forces the agent to get N messages from the thread as a context, because if not, the agent context is always empty

Still didn't review the PR, because I would like you to describe your changes, the flow, the expectations and then I will review it with that information 🙂 after the human review, several automated agents will review some extra things not related just to the code, but the coherence between the new things and the old, etc

[juanjoGonDev]

I would like keep the PR inside de scope then. I saw some pictures that are not present now (at least I can not find them anymore) with some UI changes. Of course we need them, but I would like in the first PR to have it at the same level as the other clients and then adding some extra changes.

I'm saying this because in the other clients, if you see the UI, you can select the number of messages passed from a thread to the agent. This is because in most chats, the thread is completely separated from the main conversation, so talking into a thread, forces the agent to get N messages from the thread as a context, because if not, the agent context is always empty

Still didn't review the PR, because I would like you to describe your changes, the flow, the expectations and then I will review it with that information 🙂 after the human review, several automated agents will review some extra things not related just to the code, but the coherence between the new things and the old, etc

Thanks, this helps a lot. I think I understand your point much better now.

I probably explained the scope badly from my side.

Right now, the PR is mainly doing three things:

• keeping Telegram replies inside the same topic/thread
• allowing Telegram rules to distinguish chatId and optional threadId
• adding some admin-side changes around config/testing

The flow I had in mind was:

1. a Telegram message arrives from a normal chat or from a topic
2. Magec checks whether that user/chat/thread is allowed
3. if it came from a topic, replies stay in that same topic
4. legacy Telegram configs still keep working

What I had missed is your point about thread context. After checking Slack/Discord more carefully, I see they already pass the last N thread messages to the agent. So I agree that, if Telegram is going to support topics/threads properly, the first PR should probably include that baseline too, not only the reply routing.

So for me, the core part would be:

• topic/thread-aware routing
• support for chatId + optional threadId
• the minimal UI/config needed for that, since the current flat allowedChats format cannot represent thread rules
• thread history/context support for Telegram, in the same spirit as Slack/Discord
• legacy compatibility

And the extra/follow-up part would be things like:

• richer Test flow
• extra admin-side validation/polish

So I think a better way to describe the PR is: bringing Telegram topic/thread behavior closer to the same baseline as the other threaded clients.

Also, this is my first PR to an external project, so I’m still learning how to better align with the maintainer workflow. If I’m approaching the scope the wrong way, please feel free to correct me. And thanks again for the guidance.

[achetronic]

I understand the request. Let's guide it to the success! 🙂

Something special about this project is that this is maintained not just by me, but my AI agent (living in Magec) is involved too.

As a traditional programmer, I love code quality, and agents tend to craft mesh code more times than I like to admit, buuuut there is a way to force AI agents to craft good code:

• Make important decisions in advance and force AI to follow them
• Force important restrictions and design decisions in the architectural side
• Force code revisions after important changes to assure the quality of everything
• Lastly, review everything with human expert eyes

Something I like is to assure the maintenance of the project, so I have made a lot of decisions to get it. Most of them are reflected in the directory .agents/. These files were not just generated by AI agents, but I reviewed and changed it carefully, so they contain valuable decisions and context to follow previous mentioned rules.

In your previous message, you expressed the requirements very well, but the process I need you to follow is to ask your AI agent to read all the documents in .agents/ directory before coding, just to force it to follow the same patterns :)

This is SUPER important

For example, the project is created using ADK framework, with a lot of addons done by me. And we expose ADK agents by exposing directly the REST API.

Another decision is that frontend is done with Components in Vue, to improve maintenance. And another is that there are some endpoints in the API that expose OpenAPI spec parts, this is how frontend knows which fields to put in a form and which types to expect when configuring things like clients for Discord, or Slack (the frontend changes according to what the backend expects)

When AI agents read the agentic docs, they know the clients are decoupled from API, so they are consumers, but when AI doesn't read the documents, everything is mixed as a code salad, this is the reason I ask you to do this in advance.

So as a first good issue, I need you to:

• Expose new openAPI fields for the Telegram client: allowedChannels and the number os messages for a thread (you know, the context passed to the AI when talking in a thread)
• Modify the Vue component in the frontend for exposing those fields like the other clients
• Modify the config store to persist this config in the same way the other clients do
• Be sure to produce DRY, KISS and elegant code
• If something is tricky, or difficult, we need tests. Not for everything, but for tricky things
• Documentation must be up-to-date following the same pattern used in other clients, explaining with simple language and screenshots
• Legacy compatibility is not exactly needed but should be covered automatically as this change is covering only threads, but DMs were already supported

Knowing this in advance, is there something that I forgot to mention? may be about the behavior of (channels + threads) in Telegram. I took into account just threads, but not channels. Are you wanting channel support too? In the other clients, threads are just threads inside channels