What happens
A speculative follow-up is accepted by copying the speculated files back to the working tree. If one of those copies fails, the accept still reports success in every respect except the file count:
SpeculationEvent telemetry is emitted from the .then() branch in AppContainer.tsx, so a failed accept emits nothing at all. The event that would have been emitted before the failure was fixed carried outcome: 'accepted' with an undercounted files_written, which is how this went unnoticed: there was no way to tell a good accept from a broken one in the data.
Why it matters
logSpeculation is the only place this feature is measured. A disk that is full, a read-only checkout, or a path that cannot be created makes every accept look like it never happened, which is exactly the class of failure the previous fix made visible to the user and left invisible to us. The gap will not close itself: the accept path has no other reporting.
Suggested direction
Give the accept path an outcome that covers the failure, for example outcome: 'failed' with the count of files that did not land, emitted from the .catch() branch. That needs a new value on the event type, which is why it did not belong in the PR that made the failure visible: that PR only changed applyToReal().
Worth deciding alongside it whether the failed count belongs in the event at all, or whether the existing files_written should stay at zero for a failed accept so the two cases stay distinguishable in a dashboard.
Related: #13026, which is where the copy failure started being reported to the user.
What happens
A speculative follow-up is accepted by copying the speculated files back to the working tree. If one of those copies fails, the accept still reports success in every respect except the file count:
SpeculationEventtelemetry is emitted from the.then()branch inAppContainer.tsx, so a failed accept emits nothing at all. The event that would have been emitted before the failure was fixed carriedoutcome: 'accepted'with an undercountedfiles_written, which is how this went unnoticed: there was no way to tell a good accept from a broken one in the data.Why it matters
logSpeculationis the only place this feature is measured. A disk that is full, a read-only checkout, or a path that cannot be created makes every accept look like it never happened, which is exactly the class of failure the previous fix made visible to the user and left invisible to us. The gap will not close itself: the accept path has no other reporting.Suggested direction
Give the accept path an outcome that covers the failure, for example
outcome: 'failed'with the count of files that did not land, emitted from the.catch()branch. That needs a new value on the event type, which is why it did not belong in the PR that made the failure visible: that PR only changedapplyToReal().Worth deciding alongside it whether the failed count belongs in the event at all, or whether the existing
files_writtenshould stay at zero for a failed accept so the two cases stay distinguishable in a dashboard.Related: #13026, which is where the copy failure started being reported to the user.