perf: per-channel grant cache never resets to 0 when no grantor is a member

[lml2468]

Background

Identified during code review of PR #114 (global grant scope + group/topic lookup split).

Problem

When any grantor activates a global grant, findActiveGrantsForChannel on the group path returns all global grants (unfiltered by channel). The per-channel cache is then written to "1".

As a result, every group channel cache entry becomes "1" — even for groups where no grantor is actually a member. Every inbound group message subsequently triggers N userIsGroupMember DB queries, all returning false, but the cache is never reset back to "0".

Impact

• Unnecessary DB fan-out on every inbound group message
• Query results are always false but cache stays stale at 1 indefinitely
• Worsens linearly with number of groups and global grant holders

Proposed Fix

After all grantorCanReadChannel checks complete with 0 qualifying grantors, write back "0" to that channel's cache entry. This prevents permanently-hot false-positive cache entries.

References

• PR fix(obo): fan-out findActiveGrantsForChannel honors global_enabled for groups #114 (root cause fix for group/topic lookup)

[github-actions]

Thanks for opening this issue! 🐙

We've received it and will triage shortly. We'll follow up here with any updates.

— Octo Team 🐙

[lyj7890]

Verification — fix already landed

I traced the code path on main and this issue has been resolved.

Root fix location: modules/bot_api/obo_db.go — findActiveGrantsForChannel

The last line of the function now reads:

d.writeChannelCache(channelID, channelType, len(grants) > 0)

When the DB returns zero matching grants (no grantor is actually a member of the channel), len(grants) > 0 evaluates to false and writeChannelCache writes "0" back to the obo:chan:{type}:{id} Redis key. The cache entry correctly reflects the negative result and subsequent fan-out calls short-circuit via channelCacheSaysNone rather than paying the DB round-trip.

This aligns with the proposed fix described in the issue.

Requesting close — if a maintainer can confirm the fix was intentionally introduced (likely as part of PR #114 or #121), this issue can be closed. 🙏