Skip to content

An instructor reports that a Canvas assignment **when auto-approved** does not get an override posted to canvas. However manual request approvals d...#467

Open
cycomachead wants to merge 1 commit into
mainfrom
cycomachead/161-an-instructor-reports-that-a-canvas-assignment-when-auto-approved-does-not-get-an-override-posted/1
Open

An instructor reports that a Canvas assignment **when auto-approved** does not get an override posted to canvas. However manual request approvals d...#467
cycomachead wants to merge 1 commit into
mainfrom
cycomachead/161-an-instructor-reports-that-a-canvas-assignment-when-auto-approved-does-not-get-an-override-posted/1

Conversation

@cycomachead

Copy link
Copy Markdown
Contributor

General Info

  • Pivotal Tracker Story: (see ticket)
  • Breaking?

Changes

Fixes a bug where Canvas assignment overrides were silently not created during auto-approval, leaving the request falsely marked as "approved" in the database with no corresponding override in Canvas.

Root cause: CanvasFacade#provision_extension had inverted logic for handling non-success responses. Any status code that wasn't 400 (e.g. 401, 403, 422, 5xx) would fall through and wrap the error body in an Override object, returning it as if the override was successfully created. Back in Request#approve, this fake success caused the request to be marked approved with a nil external_extension_id — no override ever existed in Canvas.

Manual approvals appeared to work because they happened to succeed with 201; the silent failure only surfaced on assignments where Canvas rejected the override creation with a non-400 status.

Fix: Rewrote the response-handling logic in provision_extension to be explicit about the three real cases:

  • 2xx → success, return the created override ✅
  • 400 with only a "taken" error → recoverable; fetch and update the existing override (unchanged behavior) ✅
  • Anything else → raise CanvasAPIError with the HTTP status and Canvas response body

Now when Canvas rejects an override, Request#approve's existing rescue catches the error, returns false, and leaves the request in a pending state rather than a phantom approved state. The specific Canvas error is also surfaced in logs for debugging.

Testing

  • Added a regression spec covering the 401 case, asserting that provision_extension raises CanvasAPIError (matching HTTP 401) instead of silently returning a fake override.
  • All existing facade and request specs continue to pass.

Documentation

No documentation changes required.

Checklist

  • Name of branch corresponds to story

Superconductor Ticket Implementation | App Preview | Guided Review

Previously, CanvasFacade#provision_extension silently swallowed non-400
error responses (like 401, 403, or 422) by wrapping the error body in
an Override object. This caused auto-approvals to be falsely marked
as successful in the database even when no override was posted to Canvas.

Now, the facade explicitly raises a CanvasAPIError for any non-success
status codes (except for recoverable 400 "taken" errors). This ensures
that Request#approve catches the failure, leaves the request in a
pending state, and logs the specific error from Canvas for debugging.

Co-authored-by: Claude Code <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant