Use cases / When production breaks
Third time in three months. Didn't we fix this in August?
The same page fires for the third time in three months, and the fix agreed after the first one still sits in an action item nobody has had time to build.
Jigward shows what the August change did and did not fix, reproduces the connection leak in a failing test and opens a tested draft fix once the engineering lead says yes. Merging, deploying and the alert threshold stay with people.
The film
Chapters
Read the narration
0:00 The same page, a third time
Third time in three months, the report worker ran out of database connections. And again, someone asks: didn't we fix this in August?
0:12 What Jigward recorded each time
I'm Jigward. I wrote this leak down in August and again in October, and Maya asked me to recheck it every weekday. Okay, let's check yesterday's page in the read-only production logs. Every failed export kept a connection, until the pool was full. Same signature as before.
0:34 What the August fix changed
The August fix? I was asked for a bigger pool. That only delays the page; the leak stayed, and my PR said so. Still there this morning. When an export fails, the worker returns before it closes its connection.
0:53 The lead says yes to an attempt
An action item from an incident review waits for someone with time. This one only needs Maya's yes. She wants a failing test first, and her click on Create starts the Task.
1:07 A failing test, then the fix
First, a test that reproduces the leak. It fails, as it should: one connection never comes back. Now the fix: the connection closes on every path. The same test passes, and so do all the other tests.
1:25 A draft pull request and the decisions left
Maya gets the history, the cause, the proof, and what I didn't check. Merging is her call. And the August question finally has an answer. The fix now waits on Maya's review, not on someone finding time. The alert threshold stays David's call.
What changes
Today. Each time the page fires, someone restarts the worker and the incident closes. The postmortem agrees the real fix as an action item, and the item waits for someone with free time. Incident trackers and postmortem documents record that a fix was agreed. They do not keep the evidence of where the defect is, check whether it is still in the code or build the fix, so the next page starts from zero.
-
Before: Someone asks whether this was fixed in August, and nobody can say for sure.
With Jigward: Every occurrence on one initiative, and the August pull request's own note that it only raised the pool size.
-
Before: A postmortem action item that waits for someone with free time.
With Jigward: An attempt that waits only for one person's yes.
-
Before: A bigger pool that only delays the next page.
With Jigward: A test that reproduces the leak, and a draft pull request that closes the connection on every path.
What Jigward does
The report worker ran out of connections again last night. Didn't we fix this in August? What happened to that fix?
Connected beforehand
- The report worker's repository is connected through GitHub.
- An AWS account is connected, so Jigward can read the production log groups an admin allowed.
- In October the lead turned on the evening review Jigward offered, which rechecks the team's initiatives against the code every weekday.
- The lead's Slack account is linked, so their direct messages reach Jigward.
-
Reads the initiative's history
In August, while raising the pool size as asked, Jigward recorded the leak at file and line as an initiative. It added the October page as a new occurrence, and last night's evening review found the leak still in the code.
-
Matches the third page
A log search over yesterday's page shows every failed export kept its connection until none was left. It is the same signature as in August and October.
-
Answers the August question
The August Task was asked for a bigger pool, and its pull request said at the time that the leak remained. The change delayed the page; it did not remove the cause.
-
Rechecks the code this morning
On the default branch as it is now, a failed export returns before the worker closes its connection. Jigward offers the fix on a Task card, and the lead's click on Create starts it.
-
Reproduces the leak, then fixes it
A new test makes one export fail and finds one connection never comes back. The change closes the connection on every path, and the test and the project's checks pass.
-
Answers in the conversation
It opens a draft pull request and answers in the same direct message with the history, the cause, the test that failed before and passes after, and what it did not check.
Jigward in this case
-
Slack
The question and the yes arrive in a direct message to Jigward. The Task card's Create button starts the attempt, and the answer comes back there.
-
Initiatives
The leak has been an initiative since August, with each occurrence on it, and the evening review rechecks it against the code on weekdays.
-
AWS CloudWatch Logs
A log search over yesterday's page finds the same signature, failed exports holding connections until the pool ran out.
-
Tasks
The attempt is a Task on the initiative, which keeps the code it read, the test runs and the diff.
-
GitHub
Jigward reads the August pull request and the code, and opens the fix as a draft pull request. It never merges.
-
Workspace
The new test, the fix and the project's checks run on Jigward's own copy of the repository.
What comes back, and what stays with the team
What comes back
- GitHub A draft pull request with the cause, the test that reproduces the leak and the change that closes the connection on every path.
- The direct message in Slack The history of three occurrences, the cause at file and line, the test that failed before and passes after, and what was not checked, with links to the Jira action item, the pull request and the Task.
What the team decides
- Reviewing, merging and deploying the fix, and closing the Jira action item. Jigward does not merge, deploy or close the issue.
- Whether the pool alert should fire earlier, which stays with the VP of Engineering. Jigward changes no alerting.
What Jigward did not check
- Behavior under real production traffic and load.
- Other code paths that may hold connections.
- Whether upload timeouts need a fix of their own.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.