step_simulation() can return without advancing t, and the caller cannot tell

[thc1006]

Flight.step_simulation() can return without advancing t, and a caller driving its own clock has no way to tell.

Two of its exits do bookkeeping and return rather than integrating:

• flight.py:926, return # Move to next phase on next call, when the current phase has no time nodes left;
• flight.py:884, which sets finished and returns once the phases run out.

Both are reasonable internally. The problem is for a caller stepping the flight alongside something else: it has no signal that the call was a no-op, so it advances its own clock while flight.t stands still, and the two drift apart.

What I measured

BalloonPoppingChallenge steps the flight once per environment step and advances its balloon positions on its own counter, so it is a direct case of this. Scenario 0 with the shipped example agent, 0.01 s steps:

environment steps	6012
calls that returned without advancing t	2
where	steps 6011 and 6012, the last two
final world_time - flight.t	0.0232 s, or 2.3 steps
popped count	10, matching the stored baseline

The important part is the second row against the third: nothing stalled mid-flight. The out-of-rail transition, which I expected to consume a call, did not. Both stalls landed at the end, after the flight had already reached the ground, so the collision sweeps that decide the score were correctly aligned throughout. A run with a rocket that never leaves the pad shows the same shape, 2 stalls out of 43 steps, both at the end.

So this is not currently costing anyone a score. I am raising it as a contract question rather than a bug report.

The check

while not flight._step_state["finished"]:
    previous_t = flight.t
    flight.step_simulation()
    assert flight._step_state["finished"] or flight.t > previous_t

Two ways to close it

Document that a call may return without advancing time, so callers know they have to read flight.t rather than count their own steps. That costs nothing and puts the burden where the caller can act on it.

Or have step_simulation() loop until it has either advanced or finished, which makes one call mean one step of simulated time and leaves existing callers correct without changes. This is the stronger guarantee but it changes how much work a single call can do.

I am happy to send either one. The first is a docstring, the second is a small loop plus a test that no call is a no-op unless the flight is finished. My preference is the second, since the whole point of a stepping API is that the caller drives the clock, but it is your call which contract you want to commit to.

[zuorenchen]

Oh wow, I didn't think there might be a bug like this. And this bug might end up being a big issue in some cases.

Therefore, we definitely want to go with the second option to make sure each call completes a step. However, we need to understand the root cause before implementing something.

[thc1006]

Sorry for the slow reply. I had measured this before filing and then never put the numbers here, which is the part you asked for.

TLDR: two early returns cause it, and on the competition path both land after the flight has already finished, so no score so far is affected.

The two places that return without touching t or y_sol, on develop at b3f1d77:

• flight.py:926, the phase transition: return # Move to next phase on next call
• the finish path just above it, where state["finished"] = True returns after post-processing

The caller has already counted a step by then, so the clocks separate.

Measured on scenario 0 with the shipped example agent, 0.01 s steps:

environment steps	6012
calls that did not advance t	2
which ones	6011 and 6012, the last two
stalls during flight, out-of-rail included	0
final world_time minus flight.t	0.0232 s
popped count	10, same as the baseline

A rocket that never leaves the pad gives the same shape, 2 of 43, both at the end.

I went in expecting an out-of-rail transition to eat an agent action and offset every later sweep. It does not happen on this path. Both stalls sit past the point where the flight is over, so the sweeps that decide a score stay lined up.

That is not an argument for leaving it. Your second option is still the one I would want, since the guarantee is what makes the API safe to build on, and the next scenario may not be so lucky. It does mean it can go in a normal cycle instead of a hotfix.

To reproduce:

while not flight._step_state["finished"]:
    previous_t = flight.t
    flight.step_simulation()
    assert flight._step_state["finished"] or flight.t > previous_t

I can send the change whenever suits you. Say the word if you would like it now.

[zuorenchen]

I think we can fix the places that return without advancing a step, so we don't need to have extra checks to make sure .step_simulation() actually steps.

flight.py:926, the phase transition: return # Move to next phase on next call

We can refactor this so it moves to the next phase in the same step to correctly advance one step

the finish path just above it, where state["finished"] = True returns after post-processing

This should be fine to leave it as is