Open Bug 1703844 Opened 3 years ago Updated 2 years ago

[QM_TRY] Track nested error propagation

Categories

(Core :: Storage: Quota Manager, enhancement)

enhancement

Tracking

()

People

(Reporter: jstutte, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

What we actually want to determine through our heuristics in bug 1700915 is the nesting level of QM_TRY and friends. Since we are looking at “propagation stacks”, it is natural to assume that this level can be bound to the error value itself. We could just count the number of QM_* macros that passed along this error.
This could be achieved by a common wrapper class around the errors. And it would be kind of the inverse variant of something similar we did for SpinEventLoopUntil, but being more loosely coupled (looking at error propagation as such, not real, compiler scoped function call nesting).

See Also: → 1709352

Ah, sorry about filing a new bug.

Depends on: 1709352
See Also: 1709352

We might want to expand this a bit (like buffering the propagation stack in memory before sending it via telemetry in case of sure error).

(In reply to Jens Stutte [:jstutte] from comment #2)

We might want to expand this a bit (like buffering the propagation stack in memory before sending it via telemetry in case of sure error).

Yeah, that might be possible, but it will require bigger changes.

(In reply to Jan Varga [:janv] from comment #3)

(In reply to Jens Stutte [:jstutte] from comment #2)

We might want to expand this a bit (like buffering the propagation stack in memory before sending it via telemetry in case of sure error).

Yeah, that might be possible, but it will require bigger changes.

Maybe not, but I guess buffering would only improve performance which seems to be ok at the moment.

For now I think bug 1709352 is more than enough. But we might want to move towards client side aggregation of equal propagation stacks in order to reduce telemetry significantly (and maybe have it even in release). And a first step for this would be to have a representation of a propagation stack in-memory.

Depends on: 1769219
Blocks: 1769244
You need to log in before you can comment on or make changes to this bug.