google

/

gemma-4-31B-it

like 2.19k

Follow

Google 52.3k

Wait... it looks like the forward can takes care of this... but the indentation is still totally wack.

OK, here's the actual bug. I figured it out:

This logic is so scuffed. They script has ns.prev_message_type which is just tracked in-loop for THIS message (not prev), to determine closing.
And prev_nt.role which is calulated each loop by searching backwards, to determine the opening.

This leads to a specific edge-case bug if you have 2 back-to-back assistant messages, but the first message has content and/or no tool responses.

In this case, on line 334, it will be ns_tr_out.flag and not message.get('content') as false, which with hit the elif not... and add a <turn|>, but the next message being an assistant message still will not open a new turn. So you'll end up with a turn with no opening <|turn> tag.

I think your second finding is the actual bug.

The problem seems to be that turn opening and turn closing are computed from different state:

• prev_nt.role is found by searching backward
• ns.prev_message_type / ns_tr_out.flag is tracked in-loop

That makes the logic asymmetric. In the consecutive assistant-message edge case, the template can emit a transition that assumes a turn is already open, but the next assistant message never gets its opening <|turn|> tag.

So this looks less like an indentation issue and more like inconsistent turn-state management. The safest fix would be to derive both open/close behavior from one shared state machine and add tests for consecutive assistant/tool transitions.

Hi @Reithan @sanjitchitturi
Thanks for reporting this. I was able to reproduce the issue for this particular edge case and have shared it with the engineering team for further review.

Here's a version of the jinja with the bug resolved. I've been using it for several days with no further issues.
https://gist.github.com/Reithan/a7431dc0c0b239688a24087bb25c0002