The Re-Engineering Round: Debugging and Verifying Fixes
Establish expected behavior from the service contract, reproduce failures with controlled inputs, and trace data flow to identify their causes. Distinguish history-dependent failures from input-dependent failures by testing with fresh service instances. Manage mutable state carefully, account for state lifetimes, and implement backtracking in graph traversal to preserve valid paths. Investigate common debugging pitfalls and practice identifying, isolating, and resolving bugs efficiently.
The first tally request returns red=2, blue=1. The second returns only blue=1, although it should return red=1, blue=1.
Before reading the whole repository, ask one question: does the second request succeed on a fresh service instance? That experiment makes request history a testable variable and tells you where to look next.
The contract comes first
The endpoint’s contract is request-local:
Each distinct event ID contributes once within a request.
Repeated deliveries of one ID have the same category.
Separate requests are independent.
Use these two requests, in order, on the same service:
Request 1:
[(E1, red), (E2, blue), (E1, red), (E3, red)]Request 2:
[(E1, red), (E4, blue)]
Before looking at any code, pick a probe that separates a history-dependent failure from an input-dependent one.
Choose the first probe
Request one returns red=2, blue=1; request two on the same service returns only blue=1. Each distinct event ID should contribute once per request, and requests are independent.
Before inspecting the implementation, which first probe and prediction best test whether retained request history causes the failure?
Reverse category sort order and repeat the sequence, predicting that red will reappear if presentation order hides it.
Delete duplicate suppression and repeat the sequence, predicting that allowing every delivery to contribute will restore the missing red.
Add one to the red count in request two, predicting red=1, blue=1 and treating that result as confirmation of the cause.
Run request two alone on a fresh TallyService, without edits. If retained history causes the failure, predict red=1, blue=1.
A request-two success on a fresh instance doesn’t mean the service works when reused. It means the failing input is fine, and the problem is state that ...