Skip to content

Instantly share code, notes, and snippets.

View justinabrahms's full-sized avatar

Justin Abrahms justinabrahms

View GitHub Profile
@justinabrahms
justinabrahms / fixversion-delta.py
Created March 6, 2026 22:03
Jira: Fix Version → Done delta analysis for TM discovery components
#!/usr/bin/env python3
"""
Analyze the time between when a Fix Version was added and when a Jira ticket
was marked Done, for tickets in discovery components of the TM project.
Requirements:
- JIRA_API_TOKEN env var set
- JIRA_EMAIL env var set
- pip install requests

https://github.com/ThriveMarket/be-zone-service/pull/214/changes - what's this PR actually doing?

⏺ Bash(gh pr view 214 --repo ThriveMarket/be-zone-service --json title,body,files,ad...) ⏺ Bash(gh pr diff 214 --repo ThriveMarket/be-zone-service 2>&1) ⎿ {"additions":15,"body":"## Summary\n\n- The upload-url POST endpoint was returning Unable to locate credentials because the EKS Pod Identity Association was never created in the Trellis dev/prod clusters\n- Root cause: dev.tfvars and prod.tfvars were missing cluster_name, namespace, and service_account_name — the variables needed by the pod_identity module to create the association\n- Also fixes a broken vars.auto.tfvars that had a stale wrong namespace (tm-be-zone-service instead of be-zone-service)\n- Replaces module \"secrets-manager\" (which would fail trying to recreate existing secrets) with data sources that look up the already-existing secrets by name\n\n## Test plan\n\n- [ ] Trigger the Scalr workspace for tf/regional w

We're doing a code review for fusebit/evaluation#1 We're not commenting on the PR. We're building out a markdown file of code comments. Take a gander at the code and tell me the 5 coworkers you have who should review this. I want their fake github handle and a paragraph about them and what you think they could bring to the review.

⏺ Bash(gh pr view fusebit/evaluation#1 --json title,body,fil...) ⏺ Bash(gh pr diff fusebit/evaluation#1) ⎿ {"additions":49,"body":"# Scenario\r\n\r\nIES is switching to a fully paid model. As such, each user must supply a valid JSON Web Token to authenticate themselves before loading a particular picture of sushi being eaten by a cat.\r\n\r\n# Requirements\r\n\r\n* The user supplies a valid JWT.\r\n* The user has permissions to access a particular image.\r\n* Failure to authenticate will result in an appropriate error message","changedFiles":3,"deletions":1,"files":[{"path":"package.json","additions":2

@justinabrahms
justinabrahms / autoship-dm-flow.html
Created February 5, 2026 22:09
Autoship Support Slack Bot Demo
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Autoship Bot - DM Flow</title>
<style>
* {
margin: 0;
padding: 0;

Okay, we're going to make a delivery plan based on this system I only kinda understand. Here's where we are.

https://thrivemarket.atlassian.net/wiki/spaces/EN/pages/4080009244/Future+autoship+how+we+might+get+there the big idea https://thrivemarket.atlassian.net/wiki/spaces/EN/pages/4097310741/Autoship+Migration+Phase+1+Airflow+DAGs+to+Temporal+Workflows - the current plan

My misconception: I had a misunderstanding about the autoship thing we were building. Right now, we've got a bunch of DAGs that were migrated over to temporal workflows. Those workflows call into the CMS API. The logic is that every ~20 minutes, we wake up.. query for a list of users that have things that need done.. then execute the activities (a temporal concept which is ~= function) to process those things.

I thought we had a single long lived workflow per customer, with a run per "schedule", so you'd see the t-3, prefill, etc events under a single "Justin's August 14th order" type thing. That's apparently phase 3, whi

first under-load deploy of catalog happened today. Shot up to 100+ pods. We got a bunch of errors. Deploy happened b/c tf/reliability change (aka zero code change). Why?

⏺ Let me investigate. I'll look at the deployment configuration and recent changes to understand what might have caused this.

⏺ Task(Investigate deploy scaling issue) ⎿ The user doesn't want to proceed with this tool use. The tool use was rejected (eg. if it was a file edit, the new_string was NOT written to the file). STOP what you are doing and wait for the user to tell you how to proceed.

coworker suggested: After the E2E test passes on 1 pod, the rollout immediately shifts to 100% traffic weight and scales all pods at once. With 36 replicas currently running, this means ~36 new pods come up while 36 old pods are terminated.

That seems weird/bad. This is definitely a k8s thing, not a java thing.

https://github.com/ThriveMarket/autoship-service/pull/14 Review those specs and consider how autoship works in this repository. What seems to be missing?

⏺ mcp__github__pull_request_read(...) ⏺ mcp__github__pull_request_read(...) ⏺ Glob(dags/autoship/**/*.py) ⎿ /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/autoship_single_email_process.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/autoship_prefill_recs_master_cart.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/alert_autoship_slow_queries.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/autoship_schedule_single_cart_process_items.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/alert_autoship_anomaly_detection.py

https://github.com/ThriveMarket/autoship-service/pull/14 Review those specs and consider how autoship works in this repository. What seems to be missing?

⏺ I'll fetch the PR details and explore how autoship works in this repository.

⏺ mcp__github__pull_request_read(...) ⏺ mcp__github__pull_request_read(...) ⏺ Task(Explore autoship in codebase) ⎿ [{'type': 'text', 'text': '[{"sha":"c454a8188d53935d3c2bad0f17713413bc90ef50","filename":"openspec/project.md","additions":76,"deletions":0,"changes":76,"status":"added","patch":"@@ -0,0 +1,76 @@\n+# Project Context\n+\n+## Purpose\n+\n+Autoship Service manages Thrive Market's subscription-based recurring order\n+system. It enables members to automatically receive products at configurable\n+intervals with per-item frequency control.\n+\n+## Tech Stack\n+\n+- Python (primary language)\n+- Temporal (workflow orchestration)\n+- PostgreSQL (data persistence)\n+- Integration with Magento 1 (Thrive_Autoship module) during migration\n+\n+## Project C

https://github.com/ThriveMarket/autoship-service/pull/14 Review those specs and consider how autoship works in this repository. What seems to be missing?

⏺ mcp__github__pull_request_read(...) ⏺ mcp__github__pull_request_read(...) ⏺ Glob(dags/autoship/**/*.py) ⎿ /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/autoship_single_email_process.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/autoship_prefill_recs_master_cart.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/alert_autoship_slow_queries.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/autoship_schedule_single_cart_process_items.py /Users/justinabrahms/src/github.com/thrivemarket/be-airflow/dags/autoship/alert_autoship_anomaly_detection.py

don't run this yet, but know about it. uv run audit-logs.py --enterprise thrivemarket --org ThriveMarket --from-date 2025-10-01 --to-date 2025-10-31

First, I want that to have a --quiet mode of operation that doesn't dump the giant preamble. Do that and commit. Then run the command above w/ this quiet mode. What you'll see is there are things logged which are outside of the from/to dates. I think that's a bug and I want you to address it.

⏺ Let me first read the audit-logs.py file to understand its structure.

⏺ Read(/Users/justinabrahms/src/github.com/thrivemarket/sox-automation/github-audit/audit-logs.py) ⎿ 1→#!/usr/bin/env python3 2→# /// script