Work Report — 2026-06-08 to 2026-06-22
Period: 8 June 2026 to 22 June 2026 Generated: 22 June 2026
Summary
The dominant theme of the period was stabilisation and feature expansion of the WALIP platform — a six-service web application for epidemiological surveillance, currently deployed across multiple countries in West Africa. The most critical delivery was fixing a silent failure in the notification service that was preventing supervisors from receiving epidemiological alert emails routed through a specific code path. In parallel, five entity types across three services received a new project-tagging mechanism that the frontend team requires to filter data by research project — work spread across 14 commits and multiple pull requests. Several sessions ran past midnight, particularly during the week of June 8–11.
What Was Delivered
1. Supervisor email alert routing — production bug fixed
Impact: Supervisors responsible for validating epidemiological results are now reliably notified by email when their action is required; previously, alerts sent via the supervisor_email_map routing path were silently discarded.
Risk removed: Without this fix, a supervisor could have missed a notification requiring urgent action on a critical sample result — with no error, no log visible to the user, and no indication the alert was ever sent. The failure was invisible.
Effort: One focused session to diagnose the broken routing path, patch the resolver logic, document the dispatch flow in the README as an ASCII diagram, and write an ITIL-format incident ticket for the Jira backlog.
2. Project-tagging across five clinical entities
Impact: The frontend application can now filter prescriptions, test requests (TDR), symptom types, conduct records, and chronic disease records by research project code — a capability that enables multi-project views previously impossible to build.
Risk removed: Without this, the frontend would have had to fetch all records and filter client-side, exposing data from unrelated projects to users who should not see it. The correct solution required a database field, a migration, and a filter endpoint — the fast workaround would have created a data-visibility gap.
Effort: Delivered across five separate pull requests over six days (June 16–18), covering three microservices (consultation, patient, analyses), with Python and SQL migrations in parallel for each entity.
3. Kafka consumer (message queue reader) reliability — hardened
Impact: The notification service's message reader now correctly tracks which messages it has processed, preventing messages from being silently lost or incorrectly replayed when the service restarts under load.
Risk removed: Two logic bugs were present that would not crash the system but would cause broken behaviour: messages could be acknowledged before processing completed, and error recovery was not triggering correctly. Had these remained, epidemiological notification data could have been silently delayed or dropped without any visible error, with the system appearing healthy.
Effort: Half a night of work (session started ~18:25, continued past midnight). The consumer was rewritten and verified in two review passes before commit, specifically because the first pass missed both bugs.
4. Platform administration feature — soft delete and full management API
Impact: Administrators can now create, update, enable, and disable laboratory platforms (the equipment categories used to classify sample analyses) through the API, without deleting records from the database — preserving historical data integrity.
Risk removed: The previous state had no soft-delete mechanism: deactivating a platform would have required a hard delete, breaking all historical analyses referencing it and making audit trails impossible to reconstruct.
Effort: Mirrored from prior work on the patient service — one session to port, add seed data, write full unit test coverage (pushing coverage from 75% to 76%), and create insert-command tests for all reference tables.
5. API documentation — access control locked down
Impact: The platform's interactive API documentation (Swagger) now requires authentication before it can be accessed. Previously, any person who knew the URL — inside or outside the organisation — could read the full list of endpoints, parameters, and data structures.
Risk removed: An unauthenticated API schema is a reconnaissance map for an attacker. Knowing all endpoint paths, expected fields, and data types cuts the effort of a targeted attack significantly. This was particularly sensitive given the platform handles patient and epidemiological data.
Effort: Identified during a management-data audit session; fixed in the same session with a targeted change to both documentation views.
6. Institut Pasteur intranet — redesigned and shipped
Impact: Institut Pasteur de Dakar now has a branded internal portal with working navigation, a workplace health and safety section, and a quick-access layout for common tools (IT ticketing, HR forms) — replacing a default Quarto template that did not reflect the institution's identity.
Risk removed: Without an accessible internal directory, staff finding tools, escalation contacts, or HR procedures were searching by memory or word of mouth — a real risk in incidents requiring fast escalation to the right person.
Effort: Two full sessions (one of which continued past midnight) for design, brand alignment, navigation restructuring, link verification on the Kubernetes deployment, and a footer redesign.
What Was Prevented
1. Silent production failure: column missing in deployment
What almost happened: A database column added to the platform management service had not been applied to the production environment via a migration. If the frontend team had called the platform listing endpoint in production before the column existed, every request would have returned a database error with no graceful fallback — taking the platform listing offline for all users in the deployed environment.
How it was caught: Spotted immediately during post-deployment testing when the endpoint returned a ProgrammingError referencing the missing column; investigated and resolved in the same session before wider use.
2. Seed data regression: earliest migrations silently broken
What almost happened: A seed data column was removed from a CSV file used by the earliest database migration without updating the migration itself. Every fresh deployment — onboarding a new country, spinning up a test environment, or running CI — would have failed silently at the data-seeding step, making the service appear correctly deployed but missing all reference data.
How it was caught: During a debugging session on the custom SQL migration tool, a full sequential replay of all migrations revealed the breakage. A regression test was then written and committed to ensure this can never recur undetected.
3. Notification consumer deployed with two silent logic bugs
What almost happened: Two bugs in the notification service's message queue reader (Kafka consumer) would not have caused crashes or visible errors. The first would have acknowledged messages as processed before the processing actually completed, meaning a restart during high load could lose messages permanently. The second prevented the error-recovery path from triggering correctly.
How it was caught: Caught during a manual code review pass before the commit was made; required two review rounds to identify both bugs.
What Is In Progress and Why It Takes Time
1. SQL-based migration tooling for controlled database updates
What it is: A custom Django management command that applies database changes using raw SQL files rather than relying solely on the framework's automatic migration tool — allowing DBAs and operations teams to review and approve the exact SQL before it runs in production.
Why it cannot be rushed: SQL migrations that include data insertion commands (via COPY) interact with database server permissions in ways that differ between local development and production environments. Rushing this risks applying partial migrations with no clean rollback path. The tool currently handles most cases correctly; the remaining edge cases involve SQL meta-commands (\copy vs COPY) that require testing against a real production-equivalent database environment.
2. Jenkins (automated build pipeline) standardisation across all six services
What it is: A shared library of build and deployment scripts to replace six separate, inconsistently maintained pipeline configurations — one per microservice.
Why it cannot be rushed: Changing a CI/CD pipeline incorrectly blocks every developer from merging code until it is fixed. The shared library has been audited for what is missing; implementation requires coordination with colleagues who maintain the Jenkins server configuration and cannot be done unilaterally.
Report covers git activity and engineering work sessions from 2026-06-08 to 2026-06-22. Generated 2026-06-22.