Too late to update it now. There's already an entry in staging. If another read request comes, it should be able to see it.

You are absolutely right - we must first set dirty bit before any write

As a workaround, users can read lakefs://repo/branch@/. Obviously in order to do this the user needs to know that this is what they want. (Alternatively, this could be an easy way to show the performance difference!)

We already know the performance difference as for example we have hard limits in DDB for read (3000/s) and writes (1000/s)

An alternative might measure dirtiness per token. Doing this could additionally reduce read pressure during commits - when read pressure can anyway be higher.

The read decision in Graveler is inherently branch-level: if any token (current or sealed) may contain entries, reads must consult staging. Tracking dirtiness per token doesn’t change that requirement and mostly adds state and maintenance complexity.

Commit-time read pressure is transient; the hot-partition issue we’re addressing is steady-state reads on clean branches. A branch-level dirty flag targets that directly with much lower risk.

Intermediate cases exist! For instance while committing a clean branch (assume appropriate flags!) there is an empty staging token but non-empty sealed tokens. This proposal forces lakeFS to consider the branch dirty even though it could know it is clean.

The correctness requirement for dirty is that if there are changes to the branch then dirty``. An additional _performance_ requirement is that if dirty` then usually there are changes to the branch.

The current version of Google protobufs has all fields optional. That means no default values. I therefore suggest using a clean field instead - the default ! false is precisely what we want.

That's a good point. We can invert the logic accordingly without changing the design

I don't understand: writes can occur concurrently with the commit, and there might even be other concurrent commits. So there may be sealed tokens, or the staging token could already be dirty. You could work around the first, but I do not see how to work around the second.
(This may be an argument in favour of dirt-per-token.)

Clearing dirty is not unconditional. It must be done via a conditional branch update that succeeds only if staging and sealed tokens are empty at that moment.
If a concurrent write or another commit introduces staged data, the condition fails and dirty remains true. False positives are acceptable; false negatives are not. This is the same concurrency pattern already used for commit ID and token rotation, and per-token dirtiness doesn’t eliminate the need for these conditional checks.