Bug: Agent loop self-replies when message IDs are non-monotonic (2.8% of sessions) #28986

Activity

1. github-actions

   assigned

   nexxeln

   on May 23, 2026
2. github-actions commented on May 23, 2026

   

   github-actionsBot

   on May 23, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of an existing issue. Please check:

   • runLoop fails to exit when client-generated messageID has clock skew ahead of server, causing infinite continuation with <system-reminder> wrap #28618: Same root cause — the runLoop exit condition uses lexicographic message ID comparison (lastUser.id < lastAssistant.id), which fails when IDs are non-monotonic. runLoop fails to exit when client-generated messageID has clock skew ahead of server, causing infinite continuation with <system-reminder> wrap #28618 documents the same bug triggered by client/server clock skew, with an identical suggested fix (use time_created timestamps instead of ID ordering). The two reports describe the same underlying defect from different angles (local millisecond-resolution collision vs. cross-host clock skew).

   If you believe this is a distinct scenario worth tracking separately, please add a comment clarifying the difference. Otherwise, consider adding your evidence and reproduction data to #28618.
3. github-actions commented on Jul 23, 2026

   

   github-actionsBot

   on Jul 23, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
4. github-actions

   closed this as not plannedon Jul 23, 2026
5. thib3113 commented on Aug 1, 2026

   

   thib3113

   on Aug 1, 2026

   Last edited by thib3113

   More actions

   I've been hitting this too, and honestly way more often than 2.8% — it felt like it happened all the time, so I decided to dig into my local database and measure it properly.

   What I did

   I have ~30k messages across ~38 days in ~/.local/share/opencode/opencode.db. I joined each assistant message to its parent user message (via the parentID field in the message.data JSON) where the pair was created within 1 second of each other, then compared the IDs lexicographically.

   Query — inversion rate

   WITH pairs AS (
     SELECT 
       u.id as user_id,
       a.id as assistant_id,
       u.time_created as user_time,
       a.time_created as assistant_time,
       u.session_id
     FROM message u
     JOIN message a ON a.session_id = u.session_id 
       AND json_extract(a.data, '$.parentID') = u.id
       AND json_extract(a.data, '$.role') = 'assistant'
       AND json_extract(u.data, '$.role') = 'user'
     WHERE ABS(a.time_created - u.time_created) <= 1000
   )
   SELECT 
     COUNT(*) as total_pairs,
     SUM(CASE WHEN user_id > assistant_id THEN 1 ELSE 0 END) as inverted,
     ROUND(100.0 * SUM(CASE WHEN user_id > assistant_id THEN 1 ELSE 0 END) / COUNT(*), 2) as pct_inverted
   FROM pairs;

   What I found

   Metric	Value
   User→assistant pairs (≤1s)	3,510
   Inverted pairs	967 (27.55%)
   Sessions affected	114 of 742 (15.4%)

   So 27.5% here, almost 10x the reported rate. But it gets more interesting when you break it down.

   Most of those inversions (824 of them) are on tool-call messages. Those don't actually matter: the loop keeps going for tool-calls anyway, so the ID order is never consulted. The inversion only matters when finish=stop, because that's the branch where the loop should exit — and that's where it fails.

   Metric	Value
   Total stop messages	2,507
   Inverted stop messages	161
   ...that produced a follow-up assistant (same parent, no user between)	161 (100%)
   Wasted follow-up messages	319
   Sessions affected	48

   So every single inverted stop produced at least one extra assistant message. Here's the query I used to find those:

   Query — self-reply detection

   WITH self_replies AS (
     SELECT a1.id as stop_id, a2.id as next_id, a1.session_id,
            CASE WHEN a1.id < json_extract(a1.data, '$.parentID')
              THEN 'INV' ELSE 'OK' END as inv,
            json_extract(a2.data, '$.finish') as f2
     FROM message a1
     JOIN message a2 ON a2.session_id = a1.session_id
         AND a2.time_created > a1.time_created
         AND a2.time_created < a1.time_created + 600000
         AND json_extract(a2.data, '$.role') = 'assistant'
     WHERE json_extract(a1.data, '$.role') = 'assistant'
       AND json_extract(a1.data, '$.finish') = 'stop'
       AND json_extract(a1.data, '$.parentID') = json_extract(a2.data, '$.parentID')
       AND NOT EXISTS (
         SELECT 1 FROM message mid
         WHERE mid.session_id = a1.session_id
           AND mid.time_created > a1.time_created
           AND mid.time_created < a2.time_created
           AND json_extract(mid.data, '$.role') = 'user'
       )
   )
   SELECT 'INV stops replied to', COUNT(DISTINCT stop_id)
   FROM self_replies WHERE inv = 'INV'
   UNION ALL
   SELECT 'OK stops replied to', COUNT(DISTINCT stop_id)
   FROM self_replies WHERE inv = 'OK'
   UNION ALL
   SELECT 'INV follow-up msgs (wasted)', COUNT(*)
   FROM self_replies WHERE inv = 'INV'
   UNION ALL
   SELECT 'OK follow-up msgs (wasted)', COUNT(*)
   FROM self_replies WHERE inv = 'OK';

   The provider angle

   I route a lot of traffic through a LiteLLM proxy, so I also split the inversion rate by provider:

   Provider	Pairs	Inversions	%
   litellm	1,710	715	41.8%
   opencode-go	939	161	17.1%
   opencode	754	106	14.1%
   antigravity-manager	121	20	16.5%
   openrouter	26	2	7.7%

   Litellm is clearly the worst, but it's not the only one — every provider shows inversions, so this isn't a proxy-only issue.

   A concrete example of what it looks like

   In one session the model replied to a question, ended with an offer to create a resource and asked "Do you want me to?" — then the loop didn't exit, the model ran again, interpreted its own question as the user confirming, and started creating the resource. The reasoning in the follow-up literally said "the user agrees" when no user had typed anything since the previous message.

   The pattern in the data is always the same:

   • user message created first (say at T)
   • assistant stop message created ~39ms later, but with an ID that sorts before the user's
   • another assistant message follows with the same parent, no user input in between

   In short: the 2.8% figure seems to only cover the pairs that inverted. In my dataset 27.5% of pairs invert, and every inverted stop — 6.4% of all stop messages — turns into an unwanted extra model run.

   ---

   Fixed by 1.18.16