feat: save token and partner data in supabase on permit generation

[zugdev]

Resolves #284

[ubiquity-os-beta]

Caution

No labels are set.

[zugdev]

@0x4007

[zugdev]

Not sure on how to QA this.

[0x4007]

[!CAUTION]
No labels are set.

@gentlementlegen caution should be reserved for application errors.

This should be a warning because its changeable based on the inputs (change the labels)

[rndquu]

Not sure on how to QA this.

Pls:

1. QA this PR, take the latest supabase backup from https://github.com/ubiquity/ubiquibot-db-backups and test the PR on your local DB instance
2. Fix failing jest CI

[zugdev]

Sorry, took some time but here is the QA! @rndquu @gentlementlegen

supabase-qa.mp4

[gentlementlegen]

@zugdev I'll have a look at it tomorrow. Does it retroactively need to fix previous permits, since the previous ones did not save this info?

[zugdev]

I will write a backfill script, apparently it makes more sense to have it here in the backend.

[zugdev]

I made a backfill script that looks into the permit's origin URL (e.g #284) and then matches all https://pay.ubq.fi/?claim= URLs. It proceeds by decoding all encoded permits and matching the signature and user with what is in the DB. If it matches it then uses the owner and token info to update the permits table with that information.

There are still some permits that don't match because they were deleted or voided. An example is permit 322, generated at ubiquity-os-marketplace/command-start-stop#2 which you have confirmed in a comment was invalidated.

To run you can simply do bun scripts/permits-backfill.ts with your .env setup: SUPABASE_KEY being the service_role secret key and not the anon key, which has no write privilege.

As of now, what allows us to fetch permits is this RLS rule.

However the table partners, for example, doesn't have that setup.

In my fork of the DB I will create the same rule, however someone with better context can decide if it's appropriate in production.

[zugdev]

added better github handling (retrials, wait on rate limit, skip on 404...)

action QA: https://github.com/zugdev/conversation-rewards/actions/runs/13557258018/job/37893854455

[zugdev]

this jest fail is from an rpc timeout. @gentlementlegen I'd be happy if you could prioritize wrapping this so I can follow up with ubiquity/pay.ubq.fi#383 (comment) :) dont worry if you cant

[gentlementlegen]

@zugdev usually when RPC times out I just relaunch tests until it picks an RPC that is fast enough. Let me restart it.

[zugdev]

@gentlementlegen done. I don't have permission to set secrets in this repo, so I'd appreciate if you could set SUPABASE_PRIVATE_KEY or give me the perms to set it.

[gentlementlegen]

I just set the private key in the environment.

[ubiquity-os-beta]

@zugdev, you have used 3 of 3 available deadline extensions. Please provide an update on your progress.

[zugdev]

Nice, @gentlementlegen can we merge and run the action?

[gentlementlegen]

@zugdev please resolve conflicts first