## Repair and Extend a Transaction Reward Processor An existing layered web service has failing unit tests. Its transaction-processing path must read a transaction file, calculate reward points for each transaction from business rules supplied with the codebase, and store the calculated rewards in a database. Some repository queries or SQL statements may also be defective. The exact file schema, database schema, and reward formulas are not available in this practice prompt. Do not invent them. Explain how you would recover those contracts from the code, tests, migrations, and fixtures before changing behavior. ### Part 1 — Triage the Failing Tests Describe how you would reproduce, classify, and minimize the failures across controller, service, parsing, reward-calculation, and repository layers. #### What This Part Should Cover - Running the narrowest failing test before the full suite. - Separating an implementation defect from a stale fixture or misunderstood contract. - Tracing one transaction identity and expected reward through each layer. - Preserving useful failure evidence rather than weakening assertions or catching every exception. ```hint Find the first wrong boundary Compare the value entering and leaving each layer; the final database mismatch may be downstream of an earlier parsing or rule-selection error. ``` ### Part 2 — Process Transactions and Apply Rules Define a robust flow for parsing the supplied file format, validating records, selecting the correct business-rule version, and computing a deterministic result for each transaction. #### What This Part Should Cover - Stable transaction identity and explicit handling of malformed or duplicate rows. - Exact numeric representation appropriate to the supplied rules. - Rule inputs, effective version, rounding or boundary semantics taken from authoritative tests or specifications. - A decision on whether one bad record rejects the file, is quarantined, or produces a per-row error. ```hint Keep rule choice observable Record which supplied rule version and normalized inputs produced a reward so a failed assertion can be reproduced later. ``` ### Part 3 — Correct SQL and Persist Atomically Explain how you would inspect and repair the database path without guessing a query from table names alone. Define the transaction boundary for inserting calculated rewards. #### What This Part Should Cover - Checking migrations, constraints, repository parameters, joins, NULL behavior, and expected result cardinality. - Parameterized SQL and explicit column lists. - An idempotency or uniqueness rule that prevents one logical transaction from earning twice. - Rollback behavior when a batch fails after some calculations have completed. ```hint Let the schema constrain the fix A query is correct only when its join keys, uniqueness assumptions, and NULL semantics match the actual migrations and fixtures. ``` ### Part 4 — Verify the Repair and Future Changes Design focused unit, repository, and integration tests for the corrected path, including rule and database boundary cases. #### What This Part Should Cover - Parser tests, rule-boundary tests, and database tests with representative fixtures. - Duplicate transaction replay and failure midway through a batch. - Evidence that the patch fixes the original failure without changing unrelated behavior. - Logs and metrics that identify the transaction and rule version without exposing sensitive file contents. ```hint Test the transaction boundary Force a persistence failure after earlier rows have been evaluated and verify that the declared atomicity contract still holds. ``` ### What a Strong Answer Covers - Uses the provided tests and schema as evidence instead of fabricating reward formulas or SQL. - Separates parsing, rule evaluation, and persistence while preserving traceable transaction identity. - Makes duplicate processing and partial database failure explicit. - Produces a small evidence-backed repair plus regression coverage at the failing boundaries. ### Follow-up Questions 1. How would you distinguish an incorrect reward formula from a transaction parsed into the wrong fields? 2. When should a malformed row reject the entire file rather than be quarantined? 3. Which database constraint would make a retry safe under the chosen reward-version semantics? 4. How would you migrate existing rewards after a rule defect is discovered?