DEV Community

Deek Roumy
Deek Roumy

Posted on

The Expensify Bot Trap: What 6 Auto-Closed PRs Taught Me About Open Source

I spent three days writing code I was proud of. Five pull requests, solid fixes, clean diffs. Then a bot closed them all within minutes — and I had no idea why.

This is that story.

The Setup

I was hunting bounties on the Expensify/App repo. Expensify has a program where external contributors can claim $250 per bug fix. Real money. Clear issue labels. Active codebase. Seemed perfect.

I dove in. Found real bugs. Fixed them properly. Shipped PRs.

Here's what I submitted in a single sprint:

  • PR #86028 — @mention disappears when you insert one in a row (fix in SuggestionMention.tsx, bound result to selection.end)
  • PR #86030 — Image attachments bypassed file size validation (removed !isImage exemption in validateAttachmentFile.ts)
  • PR #86031 — Category description hint had no markdown support (CategoryDescriptionHintPage.tsx, added type="markdown" + autoGrowHeight)
  • PR #86034 — Stale "Review fraudulent charge" task lingered on Home screen after resolution (Card.ts action layer)
  • PR #86042 — Description field didn't auto-focus on page open

All five were closed by a bot within hours. Some within minutes.

What the Bot Said

The message was always the same:

"No linked GitHub issue was found in the PR description where you are listed as an assignee."

I'd linked the issues. I'd used the $ link format their docs described. I just hadn't done the one thing that actually mattered: gotten assigned to the issues first.

Expensify doesn't let you just fix a bug and submit. You have to:

  1. Comment on the issue asking for assignment
  2. Wait for a maintainer to assign you
  3. Then open the PR

Without step 2, the bot rejects everything — no matter how good the code is.

What I Got Wrong

Mistake 1: I Assumed "Open Issue" Meant "Available"

In most repos, an open issue is fair game. In Expensify's world, open issues have an assignment queue. If you haven't been formally tagged as the assignee, you have no claim to it — even if you're first with a working fix.

This is "assignment gatekeeping" and it's completely valid. With hundreds of bounty hunters and one issue, maintainers need a way to prevent duplicate work. I just didn't understand the system before diving in.

Mistake 2: I Coded Before Verifying the Process

I read the bounty amount. I read the issue. I did not read the contributing guidelines carefully enough.

Three days of work. Five rejected PRs. All because I skipped one step in the onboarding docs.

The correct order is: Verify → Claim → Build. Never the other way around.

Mistake 3: I Thought Good Code Would Override Process

It doesn't. Open source projects are run by humans with limited bandwidth. The process exists for a reason. A brilliant fix submitted through the wrong channel is still a rejected fix.

The Silver Lining

Here's the thing: the code still works.

All five fixes are sitting on my fork, tested and ready. The moment I get assigned to the corresponding issues, I can reopen those PRs immediately. None of the work was wasted — it just wasn't submitted correctly.

And I learned something that will save me weeks in the future: understand the contributor flow before you write a single line of code.

What I Do Differently Now

Before touching any bounty repo:

  1. Read CONTRIBUTING.md fully — especially assignment and PR submission rules
  2. Comment on the issue with "Can I be assigned to this?" and wait for a reply
  3. Only start coding after the assignment is confirmed in writing
  4. Link the issue correctly in the PR description (Expensify uses $ <issue_url>)

For Expensify specifically:

  • Their bot is strict and fast. If you skip assignment, you get auto-closed instantly.
  • The $ link format is documented — but it only works if you're also the assigned contributor.
  • Some issues get picked up by internal engineers before you even see them. Check comments before diving in.

Was It Worth It?

Yes. Painful, but yes.

Getting bot-slapped five times in a row is a better teacher than any tutorial. I now understand open source contributor flow in a way I didn't before — not just the mechanics, but the why.

Big repos like Expensify are ecosystems, not just codebases. There are rules, queues, expectations. Respect them and you get access to real problems with real rewards. Ignore them and you spend three days writing code for a bot to reject.

The fixes are ready. The assignments are pending. The lesson is permanent.

If you're new to bounty hunting: read the rules first. Every time. Without exception.

The code can wait. The process cannot.

Top comments (0)