Hacker News Reader

Comment by eru | Hacker News Reader

> BUT... this is all contingent on having fast-running automated tests that can reproduce your bugs. But you should have that anyway.

Ideally, yes. But for many bugs, getting to a reproduction is already more than half the battle. And a debugger can help you with that.

View on HN

> But for many bugs, getting to a reproduction is already more than half the battle.

Today I am working on a bug where a token expires after 2 hours and then we fail to request a new one instead we just keep on using the now expired one, which (of course) doesn’t work. I have a script to reproduce it but it takes 2 hours to run. It would be great if there was some configuration knob to turn down the expiry just for this test so we can reproduce it faster - but there isn’t because nobody thought of that.

Maybe it takes less than 2 hours to add such a configuration knob?

That’s a good idea except it is in another team’s service and I’m not very familiar with their code. But I can try

Well, the hard part isn’t actually the code change (reasonably obvious) it is deploying my own copy of their service…

Can you just set the local time two hours into the future?

Or modify the expiry time locally / not use the one from the token at all.

The token isn’t being verified in my service it is being verified in a remote service. I can’t easily change the clock on the remote service. It runs in a K8S pod and (AFAIK) K8S doesn’t support time namespaces. And even if it does, the pod is deployed by a custom K8S operator so unsure if I could make the operator turn that on even if it is available. And the remote service is a complex monolith which uses lots of RAM so trying to run it on my own laptop will be painful

Reminds me of the classic adage that "everything can be solved by another layer of abstraction, except for the problem of too much abstraction layers".

Or modify the token itself so it's no longer valid? (Although that might come back with "invalid token" rather than "expired token.")

Reply on news.ycombinator.com