Repository navigation
The exported report's audit_log section was always silently empty - #100
Merged
Merged
Conversation
ExportManager._gather_session_data queried
`SELECT * FROM audit_log WHERE session_id = ? ORDER BY timestamp`, but audit_log
has neither column: it is the orchestrator's PROCESS-WIDE event log, keyed by
created_at, with no session (schema.sql says so). Every call raised into a
debug-logged try/except, so the audit_log section of every exported report was
dropped without a trace. The exporters even read `data.get("audit_log", [])`,
defaulting the hole to empty, so nothing downstream noticed either.
The prior #44 work spotted the mismatch in a comment and added the hash-chained
trail as the real record, but left the broken query in place still returning
nothing. Fixed: `SELECT * FROM audit_log ORDER BY created_at`, process-wide like
the chain, so a real row reaches the report.
Why it survived: export/manager.py's SELECTs were never run against the schema in
a test (the existing export tests use db=None, so the try/except swallows). Two
guards close that:
- export/manager.py joins test_db_schema.py's CONSUMERS. It is read-only, so it
adds no INSERTs to the write-set check, but its FROM-tables are now verified to
exist in the schema.
- a new test runs _gather_session_data against a real DatabaseEngine with a real
audit_log row and asserts the section is populated; the old query returned [].
1031 passed; bats 39/39; ruff introduces nothing new (net -1 long line).
12.1.5 -> 12.1.6.
Nerds489
added a commit
that referenced
this pull request
Sep 25, 2026
Same documenting-fiction defect the top-level README carried before its rewrite,
in the supporting docs:
docs/TOOL_REFERENCE.md headed v10.0.0, described `netreaper session`,
`netreaper crack`, `netreaper install`, `netreaper
help` and --quick/--monitor flags, none real.
docs/README.md indexed NETREAPER-GIT-HOWTO.md and
NETREAPER-FORGOTTEN-FEATURES.md, never in the folder.
ENVIRONMENT_VARIABLES.md,
SUPPORT.md "see also" links to QUICKREF/HOWTO/TROUBLESHOOTING,
also absent.
Command examples now match the real CLI (scan --type, wifi monitor/crack, web
auto, ble plan, can dump), the indexes and see-also links resolve, and the
top-level README is named as the authoritative command reference so these do not
drift into a second source of truth again.
test_docs_reference_real_commands.py guards it: a `netreaper <word>` in any
docs/*.md must be a registered command, and a sibling-doc link must resolve. It
found the dead links above, and its first run also caught my own caveat text
naming the fake commands in `netreaper <cmd>` form -- reworded so the counter-
examples do not read as real.
1033 passed; bats 39/39; ruff clean. 12.1.6 -> 12.1.7.
Stacked on #100 (fix/export-audit-log-query); merge that first.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A confirmed silent-failure bug, off the #33 roadmap (found in a survey during
this session's work, flagged, now fixed).
The bug
ExportManager._gather_session_dataqueried:audit_loghas neither column. It is the orchestrator's process-wide eventlog, keyed by
created_at, with no session (schema.sqlsays so explicitly).The query raised straight into a debug-logged
try/except, so theaudit_logsection of every exported report was dropped without a word. The exporters
read
data.get("audit_log", []), so the hole defaulted to empty and nothingdownstream noticed.
The #44 work spotted the mismatch in a comment and added the hash-chained trail
as the real record, but left the broken query returning nothing.
Fix
SELECT * FROM audit_log ORDER BY created_at-- process-wide like the chainbeside it, real column, so a row reaches the report.
Why it survived, and the guards that close it
export/manager.py's SELECTs were never run against the schema in a test (the
existing export tests use
db=None, so thetry/exceptswallows any mismatch).export/manager.pyjoinstest_db_schema.py'sCONSUMERS. Read-only, so noINSERTs to add to the write-set check, but its FROM-tables are now verified
against the schema.
_gather_session_dataagainst a realDatabaseEnginewith areal
audit_logrow and asserts the section is populated; the old queryreturned
[]. A second test pins that it is process-wide (one row shows fortwo different session ids).
1031 passed; bats 39/39; ruff introduces nothing new (net -1 long line).12.1.5 -> 12.1.6.