[JRODRIGUEZ] complete dscout interview aide coding round - #1
[JRODRIGUEZ] complete dscout interview aide coding round#1JacobBRodriguez wants to merge 1 commit into
Conversation
| if event_id is not None and event_id in seen_event_ids: | ||
| reasons.append("duplicate event_id") |
There was a problem hiding this comment.
Unhashable IDs abort event batches
event_id values like lists or dicts reach event_id in seen_event_ids, so Python raises TypeError and process_events aborts instead of adding the row to rejected_events — should we validate that event_id is a hashable scalar up front and append an event_id rejection reason first?
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 130-163 inside `process_events()`, the
deduplication block does `if event_id is not None and event_id in seen_event_ids:`
without ensuring `event_id` is hashable, so unhashable IDs crash with a TypeError
instead of producing a `rejected_events` entry. Refactor the logic to validate
hashability immediately after `event_id = event.get("event_id")` (e.g., attempt
`hash(event_id)` in a try/except); if it’s unhashable, append a rejection reason like
"unhashable event_id" and do not perform the set membership check or add to
`seen_event_ids`. Only add to `seen_event_ids` after the hashability check succeeds,
keeping the rest of the required-field and timestamp/duration validations unchanged.
| for field in REQUIRED_FIELDS: | ||
| if event.get(field) is None: | ||
| reasons.append(f"missing {field}") |
There was a problem hiding this comment.
Blank identifiers enter valid events
Empty required identifiers like event_id: "", participant_id: "", mission_id: "", and study_id: "" pass this check because only None is rejected, so invalid records reach valid_events and can be persisted with unusable IDs — should we reject blank strings explicitly, e.g. with isinstance(value, str) and not value.strip() for these fields?
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 136-138 inside `process_events()`, the
required-fields loop only treats `None` as missing (`if event.get(field) is None`), so
blank/whitespace strings like `event_id: ""` incorrectly pass and can be added to
`valid_events`. Refactor this check to also reject values that are strings which are
empty or only whitespace (e.g., `isinstance(value, str) and not value.strip()`), and
append an appropriate rejection reason (e.g., `missing {field}` or `blank {field}`) when
they occur. Update or extend the existing `run_unit_tests()` cases to cover at least one
blank required field to ensure these records are rejected, not persisted as valid.
| try: | ||
| datetime.fromisoformat(ts.replace("Z", "+00:00")) |
There was a problem hiding this comment.
Date-only timestamps enter analytics
datetime.fromisoformat() accepts date-only strings as midnight, so this exception-only check lets valid_events copy a date-only timestamp unchanged into mission_events and the Snowflake-ready output, even though Part 1 expects an ISO 8601 datetime — should we require an explicit time component before accepting the record?
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 149-152 inside the process_events() timestamp
validation block, fix the bug where datetime.fromisoformat(ts) accepts date-only strings
like "2024-01-15" and turns them into midnight, allowing non-datetime values to flow
into valid_events. Refactor the logic to explicitly require an ISO 8601 datetime format
by checking the raw ts string contains a time component (for example, require a 'T'
separator and a ':' in the time part) and only then attempting fromisoformat
normalization for the trailing 'Z'. Update run_unit_tests() around the process_events
unit tests to add a case with a date-only timestamp and assert it appears as "invalid
timestamp" in rejection_reason.
| print("\n── Unit tests: process_events() ──") | ||
| try: | ||
| run_unit_tests() | ||
| print(" ✓ All process_events() unit tests passed!") | ||
| except AssertionError as _e: | ||
| print(f" ✗ Unit test failed: {_e}") |
There was a problem hiding this comment.
Unit-test failures are silently ignored
run_unit_tests() catches AssertionError and only prints a message, so the process still exits 0 and regressions in process_events() can slip through CI — should we let the error propagate, or re-raise it after printing?
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 285-290, the bottom-of-file unit test harness
wraps run_unit_tests() in a try/except AssertionError that only prints an error and then
allows execution to continue. Change this so test failures fail the run: either remove
the except block entirely or, if you want to keep the custom message, re-raise the
caught AssertionError (after printing) so the process exits non-zero. Ensure the
caller/CI observes the failure from process_events() regressions.
Coding interview round completed for DScout.