Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Incident report for February 21st, 2024

resend.com

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Incident report for February 21st, 2024

#61

Post by pistoriusp »

doctor_eval wrote: post #59
pistoriusp wrote: post #55

Earlier quoted context omitted.

My assumption is that they connected to production to run their local environment against production to debug something. They needed the data. Snaplet can capture a small subset of data related to a particular user, and remove the private information, which they can restore on their local machine. Does that make sense?

Sure; but I assumed they logged into production to run some queries to debug an issue unrelated to dev. I mean, I know there are some bad practices out there - but connecting local dev environment to prod database server would be insane for any reason!

Yeah, it's rather crazy, but it happens. Sometimes you need to mutate things in order to get the full experience of testing the software locally. So, really you need the data locally and this is what I'm suggesting. Don't mess with the developer experience, just give them tools to self service.

Re: Incident report for February 21st, 2024

#62

Post by _andrei_ »

I hate it that some companies focus more now on how their product's website looks than on the product itself, its quality and stability. I also hate it that users are so used to having issues, errors, and their data leaked, that a startup can cut all the corners and do things completely the wrong way, and still have success. I hate that because I couldn't do it. Last month Resend leaked a database API key [0] from their env, how is that even possible? Now a developer tried to run a migration locally and did it on production, again, WHY is that possible? How can you talk about enterprise plans, SLAs, ACL features, when you can't do the basics right? What's it gonna be next month?

[0] https://resend.com/blog/incident-report-for-january-10-2024

Re: Incident report for February 21st, 2024

#64

Post by satvikpendem »

anonzzzies wrote: post #9
satvikpendem wrote: post #7

Earlier quoted context omitted.

I like that Prisma drops the database. Developer databases should be idempotent and easily reseedable with sample data. It's the same concept as cattle, not pets, from the devops world but now applied to databases. There should be nothing special about a database in development that cannot be dropped and recreated.

I don’t care about dev databases; I care about why it does it; there is no need for it, at all. > I like that Prisma drops the database. ‘Like’ ; so if it didn’t but still worked perfectly, you would complain that it didn’t?

> ‘Like’ ; so if it didn’t but still worked perfectly, you would complain that it didn’t?

Yep I would, because it maintains the idempotency invariant, plus it flushes out any bugs that may exist if databases are not idempotent from seed data, that is the "why it does it."

Re: Incident report for February 21st, 2024

#65

Post by satvikpendem »

kgeist wrote: post #15
satvikpendem wrote: post #7

Earlier quoted context omitted.

I like that Prisma drops the database. Developer databases should be idempotent and easily reseedable with sample data. It's the same concept as cattle, not pets, from the devops world but now applied to databases. There should be nothing special about a database in development that cannot be dropped and recreated.

We have a script which recreates the dev DB, but developers must run the command manually so that there was an understanding what's happening.

Sure, but that requires the developer to do so manually whereas in an automated system, it should just be self-generating and self-cleaning.
Post reply on HN