Mastering Pull Requests: Lessons from Rejected Code in LTI 1.3 Integration

The second week of open-source contribution is often where confidence meets reality. After familiarizing myself with CircuitVerse’s codebase during Week 1, Week 2 forced me to confront the raw gap between writing functional code and delivering something that the project maintainers would actually accept. It was a week of rejected pull requests, critical feedback, and a frustrating two-day detour caused by a single two-letter word in Ruby. Yet by the end of it, I had a polished change ready for review—one that clears the path for CircuitVerse’s full transition to LTI 1.3 integration with Canvas LMS.

Why LTI 1.3 Matters for Educational Tools

CircuitVerse is an open-source platform where students design and simulate digital circuits directly in their browser. To connect it seamlessly with Canvas, one of the world’s most widely used Learning Management Systems, the project relies on LTI (Learning Tools Interoperability). LTI acts as a standardized plug that lets any educational tool integrate with any LMS without forcing students to juggle multiple logins or leave their course pages.

There are two versions of LTI in active use today. LTI 1.1 is older, simpler, and relies on OAuth 1.0 for authentication. LTI 1.3, by contrast, is the modern, more secure standard that Canvas officially recommends. My goal this summer is to upgrade CircuitVerse from LTI 1.1 to LTI 1.3, ensuring compatibility with current security practices and future-proofing the integration.

Monday and Tuesday: The Pull Request That Went Off the Rails

I began the week confidently, submitting a pull request intended to fix a bug in CircuitVerse’s existing LTI 1.1 grade passback system. “Grade passback” refers to the process where CircuitVerse automatically sends a student’s assignment score back to Canvas after completion. The fix seemed straightforward—until two reviewer comments exposed critical oversights.

The first comment read: “It seems that the whole schema is sorted. This issue has been fixed upstream.”

In other words, I had accidentally included a massive, unrelated change to schema.rb, a file that defines the structure of CircuitVerse’s database. When I ran a Rails command to regenerate this file locally, a recent Rails update had quietly reordered every database column alphabetically. The resulting diff showed hundreds of changed lines—none related to my intended fix. The reviewer caught it in seconds.

The second comment struck even closer to home: “You are downgrading gem version here.”

CircuitVerse uses the jwt library for secure identity verification. A recent upgrade had moved jwt from version 2.x to 3.x. My branch, however, had unknowingly reverted it back to the older version due to a dependency chain reaction. Another library I had updated, webpush (used for browser notifications), was incompatible with jwt 3.x and had silently pulled the version back down without my awareness.

Restoring Sanity: A Step-by-Step Fix

• I restored schema.rb to match the main branch exactly.
• I upgraded jwt back to version 3.2.0 and downgraded webpush to the last compatible version.
• Using Git commands, I carefully undid the unintended changes, re-committed, and pushed the corrected version.

This taught me a lasting lesson: always inspect your diff before opening a pull request. A diff reveals every line changed—expected or not. If something looks unfamiliar, it probably shouldn’t be in the PR.

Wednesday: Closing a PR That Wasn’t Ready

After addressing the reviewer’s concerns and resubmitting, I received hard feedback: the PR had to be closed. The grade passback code I’d written relied on the outdated ims-lti library, which used LTI 1.1’s OAuth 1.0 authentication. The problem ran deeper than I realized—several other files in the project depended on the same library, and changing it risked breaking unrelated functionality.

It was frustrating to close a PR I’d worked on carefully, but my mentor guided me toward the right solution: before fixing the grade passback flow, I first needed to upgrade the underlying library to one that supports LTI 1.3 properly.

Reviewing Another Developer’s Code: A Crash Course in Critical Thinking

While regrouping, I was asked to review a Dependabot-generated pull request proposing to upgrade ims-lti from version 1.2.9 to 2.3.7. This turned out to be an invaluable exercise in evaluating code changes.

By examining the changelog and diff, I discovered that version 2.x of ims-lti had dropped support for the OAuth library entirely—the same one used by LtiScoreSubmission, the module responsible for grade passback. Even more concerning, a core class called IMS::LTI::ToolProvider, used to verify student identity during LTI launches, no longer existed in 2.x.

I documented these findings in a detailed review and recommended the PR be postponed until the LTI code was fully migrated to 1.3. The PR was not merged. This experience underscored that reviewing others’ code isn’t just about syntax—it’s about understanding how changes ripple across the entire system.

Thursday: The Hidden Complexities of Syncing with Upstream

Before writing new LTI 1.3 code, I needed to ensure my local copy of CircuitVerse was synchronized with the latest changes from the official repository. The process is called “fetching upstream,” and it’s supposed to be routine. This time, it wasn’t.

Git commands like git fetch upstream and git rebase main should pull in upstream changes cleanly. Instead, I encountered merge conflicts in files I hadn’t touched. The root cause? A recent Rails upgrade had changed how timestamps were handled in database migrations, and my local setup had fallen out of sync with the main branch.

After several failed rebases and a refresher on Git’s conflict resolution tools, I finally managed to align my branch with the upstream code. The experience reinforced a principle that applies beyond open source: keeping dependencies updated and understanding their behavior prevents costly surprises down the line.

Looking Ahead: From Rejection to Readiness

This week wasn’t just about rejected pull requests—it was about learning to write code that survives review. Every rejection, every critical comment, and every merge conflict brought me closer to understanding not just how CircuitVerse works, but how open-source projects thrive: through collaboration, scrutiny, and relentless attention to detail.

Next week, I’ll begin implementing the actual LTI 1.3 integration—the real milestone. It won’t be easy, but with a clearer understanding of the project’s architecture and the discipline to validate every change, I’m ready to move forward with confidence.