fix: use minute-level granularity for MOIM timestamps

[sihyeonn]

Summary

Fixes agent infinite loop caused by second-level timestamp changes in MOIM (Minus One Info Message) injection.

Problem

Agent repeatedly updates files every 5-7 seconds, only changing the datetime comment:

editing /Users/user/Work/Oss/AIP/apisix/scripts/adc-preload.sh

# First edit - adds timestamp comment
old_str: #!/bin/bash # ADC Script...
new_str: #!/bin/bash # ADC Script...
         #
         # <info-msg>
         # Datetime: 2025-12-29 09:06:51
         # </info-msg>

# 7 seconds later - updates only timestamp
old_str: # Datetime: 2025-12-29 09:06:51
new_str: # Datetime: 2025-12-29 09:06:58

# 5 seconds later - updates again
old_str: # Datetime: 2025-12-29 09:06:58
new_str: # Datetime: 2025-12-29 09:07:03

# Continues indefinitely...

Root Cause

1. collect_moim() generates timestamp with second-level precision (%Y-%m-%d %H:%M:%S)
2. This <info-msg> is injected into conversation via inject_moim()
3. Agent interprets it as file content and adds as comment
4. Next turn (5-7s later): new timestamp → agent detects "outdated" datetime → updates file
5. Repeat forever

Solution

Use minute-level granularity by fixing seconds to :00:

// Before: Changes every second
let timestamp = chrono::Local::now().format("%Y-%m-%d %H:%M:%S").to_string();

// After: Changes every minute
let timestamp = chrono::Local::now().format("%Y-%m-%d %H:%M:00").to_string();

This keeps conversation stable within a 1-minute window, preventing infinite loop for 99% of use cases (tasks completing within 1 minute).

Impact

• Minimal change: Only 1 line modified + 1 simple test added
• No breaking changes: Existing behavior preserved
• All tests pass: No modifications to existing tests needed
• Practical solution: Solves the issue for typical agent tasks

Type of Change

• Bug fix
• Performance improvement

AI Assistance

• This PR was created or reviewed with AI assistance

Testing

Added test to verify minute-level granularity:

#[tokio::test]
async fn test_collect_moim_uses_minute_granularity() {
    let em = ExtensionManager::new_without_provider();
    if let Some(moim) = em.collect_moim().await {
        assert!(moim.contains(":00\n"), "Timestamp should use minute granularity");
    }
}

All existing tests continue to pass (6 existing + 1 new = 7 total).

Manual testing confirmed the infinite loop no longer occurs for tasks completing within 1 minute.

Related Issues

Builds on #6101 which changed datetime format from "Datetime:" to "It is currently" to help LLMs recognize the current year.

While #6101 improved LLM understanding, it didn't address the infinite loop issue caused by second-level timestamp changes. This PR completes the fix by using minute-level granularity.

Relates to #6066

Screenshots/Demos (for UX changes)

[michaelneale]

thanks @sihyeonn do you mind updating this to main and resolving conflicts?

[sihyeonn]

@michaelneale thanks, I handled

[michaelneale]

thanks @sihyeonn I think it makes sense. Nice to have a simple test and worth having. I'll tag @tlongwell-block who has spent time on MOIM just in case we need to walk this back if there is some unexpected side effect but I think worth it.

[DOsinga]

can you explain this more, @michaelneale @sihyeonn ? how does this happen? the MOIM message is only supposed to added on a user message, how does the agent reactivate based on this? and it does, how does changing this to minutes from seconds help?

from the logs it looks more to me that this is adding the MOIM in the wrong place

[tlongwell-block]

This makes sense to me @DOsinga

Weaker models will see that we're providing the current time, then notice that the file they wrote last turn (that includes a timestamp for some reason) is not matching what is provided and think its an error.

Then it updates the file on the next turn... at which point the timestamp we provide it has already updated again...

[DOsinga]

Look at the screenshot, the replacement string it is trying to insert contains the moim. not the timestamp, the entire MOIM. that suggests to me that something is going rather wrong here. I'd love to see the exported converstation here to see what actually happened (or better the diagnostics)

# First edit - adds timestamp comment
old_str: #!/bin/bash # ADC Script...
new_str: #!/bin/bash # ADC Script...
         #
         # <info-msg>
         # Datetime: 2025-12-29 09:06:51
         # </info-msg>

Even if your theory is correct than this is not the solution. The solution would be to insert a stable timestamp based on when the interaction with the agent for this cycle begins, not rounding it up to a minute. longer interactions can easily take a minute so this is just not going to solve this.

[sihyeonn]

@tlongwell-block That's exactly what I experienced.

@DOsinga

longer interactions can easily take a minute so this is just not going to solve this.

Agreed. Minute-level granularity is only a partial fix. I’m planning a follow-up PR so that collect_moim() returns None when there’s no platform content. That way, the block won’t be injected at all unless there’s actual content to include.

This should also help with another related issue I noticed: the model seems to interpret <info-msg> ... </info-msg> as a user message (see screenshot).

Just in case, I’m adding the Korean message from the screenshot verbatim (translation aid):

무시해도 됩니다. 그 <info-msg> It is currently ... </info-msg>는 **Test::Nginx가 stdout에 찍는 “진단용 메시지”**라서, APISIX/etcd/CAS 문제의 원인이 아닙니다. (레포에서 grep 안 잡히는 것도 정상)

[tlongwell-block]

Having the current time/date is probably a good thing since sessions can be resumed hours/days/weeks apart

The minute granularity is not a complete fix, but it will probably provide enough buffer for goose to get through a few more messages/actions and stop futzing with that particular file edit

The MOIM is a user message, implementation-wise

[DOsinga]

Having the current time/date is probably a good thing since sessions can be resumed hours/days/weeks apart

that's not what I am saying; I'm saying we shouldn't change the timestamp during the interaction with the agent.

if you remember when we were implementing this I was reluctant to have the MOIM update at all during the agent tool calling loop; this report including the fact that models might have trouble make me think that we should think about that again. MOIM always being part of the last user message that is actually from the user side steps these issues