You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
chatApp messages stored as events only — pruned by RPC providers over time #598
In chatApp/chatApp.sol:6-9, messages are emitted as events but never stored in contract state. Events are pruned by many RPC providers, making old messages permanently unretrievable.
There’s also a recoverable startup gap in the current reader, separate from provider retention. In loadAllExistingMessages(), a failed history query is logged and swallowed; initializeApp() then starts the new-message checker at the current head. Old messages can therefore disappear from this session even when the RPC could serve them on a later attempt.
I reproduced that offline with the existing browser script and stubbed Web3: the initial 0 → latest request fails, but the next request starts at block 101 after fixture heads 100/101. Original: 1 control passes, 1 regression fails. Propagating that initial error stops polling and gives 2 passes; that’s a diagnostic check, not a complete history fix. Reproduction and logs.
A useful first fix is to show “history unavailable” and keep the unfilled range pending instead of silently treating startup as complete. Bounded backfill from the deployment block, a persisted checkpoint, and explicit coverage gaps would address the longer-term reader. No live RPC or deployed app was tested.
Thanks for the detailed reproduction! Please open a focused PR to show “history unavailable,” preserve the missing range for retry, and add a regression test. We’ll keep this issue open for the RPC retention concern.
Activity
github-actions commentedon Oct 28, 2026
👋 Thank you for opening this issue. We will review it and get back to you soon. — th30d4y
gjwang commentedon Nov 2, 2026
There’s also a recoverable startup gap in the current reader, separate from provider retention. In
loadAllExistingMessages(), a failed history query is logged and swallowed;initializeApp()then starts the new-message checker at the current head. Old messages can therefore disappear from this session even when the RPC could serve them on a later attempt.I reproduced that offline with the existing browser script and stubbed Web3: the initial
0 → latestrequest fails, but the next request starts at block 101 after fixture heads 100/101. Original: 1 control passes, 1 regression fails. Propagating that initial error stops polling and gives 2 passes; that’s a diagnostic check, not a complete history fix. Reproduction and logs.A useful first fix is to show “history unavailable” and keep the unfilled range pending instead of silently treating startup as complete. Bounded backfill from the deployment block, a persisted checkpoint, and explicit coverage gaps would address the longer-term reader. No live RPC or deployed app was tested.
0x5t4l1n commentedon Nov 2, 2026
Thanks for the detailed reproduction! Please open a focused PR to show “history unavailable,” preserve the missing range for retry, and add a regression test. We’ll keep this issue open for the RPC retention concern.
0x5t4l1n commentedon Nov 2, 2026
If you’re interested, feel free to work on this. I’ve assigned it to you.