Allow to set in your account bundle retention

[riderx]

I can set after X days my old bundle will be removed. Create_at has to be before than now - days. Bundle meta updated_at has to be before than now - days. Bundle has to be not in use in any channel

[riderx]

/bounty $150

[algora-pbc[bot]]

💎 $150 bounty created by riderx 🙋 If you start working on this, comment /attempt #257 to notify everyone 👉 To claim this bounty, submit a pull request that includes the text /claim #257 somewhere in its body 📝 Before proceeding, please make sure you can receive payouts in your country 💵 Payment arrives in your account 2-5 days after the bounty is rewarded 💯 You keep 100% of the bounty award 🙏 Thank you for contributing to Cap-go/capgo!

Attempt	Started (GMT+0)	Solution
🟢 @akhill10	Aug 10, 2023, 1:26:29 PM	#275
🟢 @WcaleNieWolny	Aug 17, 2023, 4:57:17 AM	#273

[akhill10]

Hello @riderx , I would like to take this up.

If I understand it correctly, we need to perform the following tasks:

1. Introduce a new column retention to the apps table which stores the day's value. And an API to upsert the retention value for the apps
2. A cron job that runs every day, which is responsible for checking the app_versions table and set the bundles deleted to true for those whose created_at has to be before than now - days, updated_at has to be before than now - days and bundle has to be not in use in any channel. And also responsible for deleting the corresponding buckets.

/attempt #257

Options

• Cancel my attempt

[riderx]

Hello thanks for the questions:

• yes for the new column, but no need for API since we use Supabase it will just be done with Supabase SDK what is necessary is allowing setting it from the CLI. With a new command npx @capgo/cli@latest app set [appId] --retention if they put 0 then it's infinite.
• yes, but the cron has to look at created_at and last update of app_versions_meta. We don't want to delete version who have been in use in retention period. app_versions_meta is update each time user download the bundle. You have also to check if app_versions is not in use in any channel, if yes they are ignored.

Then when you delete is same as current workflow you delete the storage but not the row in the db for stats purposes

[akhill10]

@riderx Thanks for more information.

But I am facing a hard time setting up the project in local. supabase start throwing an error. Basically it's not initialising the schema from schema.sql.

Seeding data supabase/seed.sql...
ERROR: relation "public.plans" does not exist (SQLSTATE 42P01)
Try rerunning the command with --debug to troubleshoot the error.

Can you please help me out ?

[riderx]

I just updated the repo with new schema yesterday. Maybe that could help you to pull ? Then try see if your cli supabase is the latest

[akhill10]

@riderx Yeah, I am on the latest commit and also latest supabase cli 1.83.7

[riderx]

I will check Monday

[WcaleNieWolny]

@akhill10 Can I attempt this? I already have supabase set up and it works on my machine

[akhill10]

@WcaleNieWolny I have already started working on it. Wrote the business logic for the cron job. Waiting to test it locally before I raise a PR. But not able to set up locally due to this migration/schema issues. I also see another person's PR is also facing a similar issue.

If you can share steps on how you're able to run this, then it is much appreciated. Thanks in advance.

[riderx]

@akhill10 i fixed the seed db you should be able to start in local now

[akhill10]

@riderx Thank you, able to start local now 😄 Will raise a PR soon.

[WcaleNieWolny]

/attempt #257

Options

• Cancel my attempt

[algora-pbc[bot]]

Note: The user @akhill10 is already attempting to complete issue #257 and claim the bounty. If you attempt to complete the same issue, there is a chance that @akhill10 will complete the issue first, and be awarded the bounty. We recommend discussing with @akhill10 and potentially collaborating on the same solution versus creating an alternate solution.

[algora-pbc[bot]]

💡 @WcaleNieWolny submitted a pull request that claims the bounty. You can visit your org dashboard to reward.

[akhill10]

@WcaleNieWolny Perhaps before contributing, you should have asked the attempted person if they have started work. Otherwise, it will be duplicate work and wastes another person's valuable time 😞

[WcaleNieWolny]

I know that you had started working on this, but my solution is completely different then yours is. I used a SQL statement to minimize complexity and the potential attack surface for a DDoS attack and you wrote an edge function. My PR does not solve only this, but also resolves (partially) the issue that made webhooks not run (https://github.com/Cap-go/capgo/issues/270) As far as I know you have not checked the actual S3 removal or at least did not see that this functionality is already implemented

[WcaleNieWolny]

I do however believe your CLI PR is better. Mine is functional but nothing more.

[riderx]

Sorry, guys, this is happening. I can maybe find a middle ground for you.

I currently like the PR for "backend" better from @WcaleNieWolny And the one from CLI better from @akhill10

So what I can do is create a bounty for CLI as well for $50 : https://github.com/Cap-go/CLI/issues/122

Reduce this one to 150$ Create a new bounty for the big fix @WcaleNieWolny made for the bundle delete, who was broken. For $50

[algora-pbc[bot]]

🎉🎈 @WcaleNieWolny has been awarded $150! 🎈🎊