Capstone day. One function, three APIs, every defensive pattern from this track baked in. What does the returned receipt need to show so the caller can log a full audit of each run?
Counts for each source, the list of task titles written, and a status? So a single dict has five or six keys that map to each step?
Exactly. Every step gets its own key. The outer dict is an audit log for one execution:
receipt = {
"emails": email_count,
"events": event_count,
"tasks_created": created,
"status": "ok",
}And the orchestrator combines the safe-read wrapper from Day 24, the per-item guard from Day 26, and the validated send from Day 27 — each in its own section of the function?
Stack the patterns you already know. Read defensively, write defensively, report everything. Sixteen lines end to end:
def orchestrate(max_each: int) -> dict:
try:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_each})
messages = emails.get("messages", [])
except Exception:
messages = []
try:
events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})
event_count = len(events.get("items", []))
except Exception:
event_count = -1
created = []
for m in messages:
try:
toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": m.get("snippet", "")})
created.append(m.get("snippet", ""))
except Exception:
continue
return {"emails": len(messages), "events": event_count, "tasks_created": created, "status": "ok"}If every defensive wrapper is in place, can this function ever actually fail? Or does the orchestrator itself need a top-level try/except?
Every API boundary is guarded — the wrappers cover network failures, missing keys, and bad writes. The only way this function raises is a local bug in your own code, which a top-level try/except would hide and hurt. Let local bugs propagate so you catch them in dev.
So this sixteen-line function is the whole track — three APIs, two weeks of reads, two weeks of writes, four weeks of defence, all in one return?
One cron-ready function. You can schedule this tonight, log the receipt dict for six months, and the script will still be running in the background — quietly doing what used to take half your morning.
TL;DR: Every pattern from this track stacks into one defensive multi-API function.
execute_actionstatus| Failure | Handled by |
|---|---|
| Gmail down | Outer try/except → empty messages list |
| Calendar down | Outer try/except → event_count = -1 |
| One task write fails | Inner try/except → skip one, continue |
| Missing list key | .get(key, []) default |
Four layers, sixteen lines, zero crashes. That is the finish line for this track.
Capstone day. One function, three APIs, every defensive pattern from this track baked in. What does the returned receipt need to show so the caller can log a full audit of each run?
Counts for each source, the list of task titles written, and a status? So a single dict has five or six keys that map to each step?
Exactly. Every step gets its own key. The outer dict is an audit log for one execution:
receipt = {
"emails": email_count,
"events": event_count,
"tasks_created": created,
"status": "ok",
}And the orchestrator combines the safe-read wrapper from Day 24, the per-item guard from Day 26, and the validated send from Day 27 — each in its own section of the function?
Stack the patterns you already know. Read defensively, write defensively, report everything. Sixteen lines end to end:
def orchestrate(max_each: int) -> dict:
try:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_each})
messages = emails.get("messages", [])
except Exception:
messages = []
try:
events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})
event_count = len(events.get("items", []))
except Exception:
event_count = -1
created = []
for m in messages:
try:
toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": m.get("snippet", "")})
created.append(m.get("snippet", ""))
except Exception:
continue
return {"emails": len(messages), "events": event_count, "tasks_created": created, "status": "ok"}If every defensive wrapper is in place, can this function ever actually fail? Or does the orchestrator itself need a top-level try/except?
Every API boundary is guarded — the wrappers cover network failures, missing keys, and bad writes. The only way this function raises is a local bug in your own code, which a top-level try/except would hide and hurt. Let local bugs propagate so you catch them in dev.
So this sixteen-line function is the whole track — three APIs, two weeks of reads, two weeks of writes, four weeks of defence, all in one return?
One cron-ready function. You can schedule this tonight, log the receipt dict for six months, and the script will still be running in the background — quietly doing what used to take half your morning.
TL;DR: Every pattern from this track stacks into one defensive multi-API function.
execute_actionstatus| Failure | Handled by |
|---|---|
| Gmail down | Outer try/except → empty messages list |
| Calendar down | Outer try/except → event_count = -1 |
| One task write fails | Inner try/except → skip one, continue |
| Missing list key | .get(key, []) default |
Four layers, sixteen lines, zero crashes. That is the finish line for this track.
Create a free account to get started. Paid plans unlock all tracks.