EFIAL-458-config/dependencies and EFIAL-459-partner-sync by rtavernaea · Pull Request #76 · edanalytics/runway

rtavernaea · 2026-06-08T15:42:02Z

This PR addresses EDFIAL-458 and EDFIAL-459.

EDFIAL-458:

Add config for UM & Tx sync
- Texas specific secret & TX_SYNC_CRON
  - I think both syncs could potentially end up using the same SYNC_CRON value but kept them separate for now
PartnerSyncCoordinator handles scheduling and kicking off each sync based on what config values are available.
- Right now it goes through all of the possible handlers each time the app starts up. Alternatively it could check the db first for only sync handlers that are currently implemented. This might be more efficient but would mean we have to add an initial partner to register the sync method.

EDFIAL-459:

Both syncs share the same pg-boss connection

user_management_sync
- Mirrors exsiting connection and transactions from Podium sync
- No children/metatenancy for now
- Partners not sync-managed (i.e., sync_managed: null) are left alone by the sync
tx_sync
- Empty for now. Need to land on the best approach for this between options laid out in EDFIAL-460

edandylytics

Still taking it in and need to try it out. Overall, it's looking pretty good -- just a few early thoughts in the comments.

One scope update; let's hold off on including any of the TX config or other components until we're building that piece. The enum value is fine, but it's hard to tell whether the rest is correct until we're actually building the TX sync

edandylytics · 2026-06-25T21:10:01Z

+      const partnerIdsToDelete: string[] = [];
+      const partnerIdsToUndelete: string[] = [];
+
+      if (partnersResult.status === 'success') {


I think we should stop early if the partner request fails. Continuing to sync tenants is probably fine, but I find it difficult to reason about its correctness.

edandylytics · 2026-06-25T21:14:40Z

+        }
+
+        for (const partner of existingPartners) {
+          if (!!partner.managedBy && !partner.deletedOn && !apiPartnerCodes.has(partner.id)) {


Where do we check that the partner we're deleting is managed by this specific sync? E.g. TX doesn't delete UM partners and vice verse?

Oh right, I wasn't thinking of that but I guess we need it because there is a tx partner in UM?

Yep -- TX being in the UM results is a clearer case than the one I mentioned. Here's how I think about it: It's Runway's job to determine which partners each sync manages. Runway shouldn't trust external systems to say which partners it can update. That means we need to ensure that it's Runway's internal state (partner.magagedBy) that scopes the sync, not what the external systems report.

edandylytics · 2026-06-25T21:19:44Z

+            return;
+          }
+
+          const tenantMap: Map<string, GetTenantDto> = tenantsByPartner.get(partnerId) ?? new Map();


Can this be Tenant instead of GetTenantDto? Looks like it holds tenants from Prisma, not tenant DTOs. They're mostly the same shape today, but we could update the DTO in a way that'd break this

snyk-io-us · 2026-06-26T13:14:01Z

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

edandylytics

A couple more comments.

edandylytics · 2026-06-25T21:27:29Z

+    const url = this.get('UM_URL');
+    const auth0Domain = this.get('UM_AUTH0_DOMAIN');
+    const clientId = this.get('UM_CLIENT_ID');
+    const clientSecret = this.get('UM_CLIENT_SECRET');


Deployed environments will need to look up credentials in an AWS secret. You can check out other methods on this service for how to use a secret and fall back to env vars if a secret doesn't exist. postgresPoolConfig is a good example.

edandylytics · 2026-06-26T14:54:01Z

+        }
+
+        for (const partner of existingPartners) {
+          if (!!partner.managedBy && !partner.deletedOn && !apiPartnerCodes.has(partner.id)) {


Yep -- TX being in the UM results is a clearer case than the one I mentioned. Here's how I think about it: It's Runway's job to determine which partners each sync manages. Runway shouldn't trust external systems to say which partners it can update. That means we need to ensure that it's Runway's internal state (partner.magagedBy) that scopes the sync, not what the external systems report.

edandylytics · 2026-06-26T14:59:35Z

I think we should probably refactor away from this coordinator class. It looks like it does two things:

Initialize PgBoss and manage its lifecycle

Start up the sync

For PgBoss, I expect we'll be using that in other places in the app soon and it'd be helpful to have that as it's own injectable component that can be shared.

Once you remove the PgBoss initialization, do we need a coordinator? It seems each sync service could start itself in its own OnModuleInit. Then we don't need the getSyncConfig wrapper either.

Let me know if I'm missing something there, though.

rtavernaea added 22 commits June 5, 2026 08:40

migration

c47ff3a

tests

ab75b20

add fields to created-modified

e148d6d

sync module

37aa864

envs

321debe

alconfig

03ee108

remove erroring line

93bbedc

test file

84e1ef1

spec

a253024

add top level error boundary

c520d39

revisit

faafabf

wip

b165636

remove children

8695346

tests

5b78956

add enum

e701747

merge

a0ea1d8

global

31a1cef

merge

c37b904

fix test

d4d0919

config

405fac6

tx

fd076f4

fix test

a8e3b8d

rtavernaea changed the title ~~Edfial 458~~ EFIAL-458-config/dependencies and EFIAL-459-partner-sync Jun 18, 2026

rtavernaea added 7 commits June 25, 2026 11:06

merge

1ad5dff

rename manager

ec20826

remove duplicate const

323dc4b

remove managedby from tenant

2cd998a

remove managedby

b8ddc88

dont delete non sync managed partners absent from UM

16c6398

iterate over handlers

c4972f2

rtavernaea marked this pull request as ready for review June 25, 2026 17:49

rtavernaea requested a review from edandylytics June 25, 2026 18:03

rtavernaea added 2 commits June 25, 2026 13:36

change al to um

6c84e84

simplify handlers

d33d450

edandylytics reviewed Jun 25, 2026

View reviewed changes

rtavernaea added 2 commits June 26, 2026 08:11

check sourcekey is sync manager

ce5aea9

remove tx reference

1dd4ab2

rtavernaea added 2 commits June 26, 2026 08:15

remove newline

bb8b7fb

test

5a04bd8

edandylytics reviewed Jun 26, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

EFIAL-458-config/dependencies and EFIAL-459-partner-sync#76

EFIAL-458-config/dependencies and EFIAL-459-partner-sync#76
rtavernaea wants to merge 35 commits into
developmentfrom
EDFIAL-458

rtavernaea commented Jun 8, 2026 •

edited

Loading

Uh oh!

edandylytics left a comment

Uh oh!

edandylytics Jun 25, 2026

Uh oh!

edandylytics Jun 25, 2026

Uh oh!

rtavernaea Jun 26, 2026

Uh oh!

edandylytics Jun 26, 2026

Uh oh!

edandylytics Jun 25, 2026

Uh oh!

snyk-io-us Bot commented Jun 26, 2026 •

edited

Loading

Uh oh!

edandylytics left a comment

Uh oh!

edandylytics Jun 25, 2026

Uh oh!

edandylytics Jun 26, 2026

Uh oh!

edandylytics Jun 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

rtavernaea commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

EDFIAL-458:

EDFIAL-459:

Uh oh!

edandylytics left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

snyk-io-us Bot commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Snyk checks have passed. No issues have been found so far.

Uh oh!

edandylytics left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rtavernaea commented Jun 8, 2026 •

edited

Loading

snyk-io-us Bot commented Jun 26, 2026 •

edited

Loading