This'll be something for @Brody to look into when he gets back

Is there anything I can do to help you triage this behaviour? I just deployed and it happened again

hey there, Adam tagged me when I was on PTO, and we had this monday off as it's a holiday.

I will be trying to reproduce this.

Hi Brody! Sorry, I had no idea there was a holiday

I'm under the impression Railway does something of this sort when a new deploy is triggered

In my case, I'd expect it to check if RAILWAYDEPLOYMENTOVERLAP_SECONDS = 0 and in that case the start container action should be triggered only once the stop container one completes

for fun, try setting it to a negative value

I thought about that but I didn't dare, let me try right away

the worst that can happen is that the variable would be ignored

Unfortunately the behaviour persists

how urget is this, aka is this blocking something you are doing? or is it just an annoyance?

No urgency at all, it was just something I noticed very long ago and was worth reporting

ah gotcha, this isnt affecting you at all?

Nope, I only face a few seconds of overlap which results in a couple of error logs

well we dont want error logs

hello, we won't be able to prioritize this issue at the moment, for now please add a sleep to the start of your app if its needed.

Hey Brody! Somehow I missed your reply so apologies for that
It really is fine if the team can't act on it for the time being, do you know / are you allowed to share if it will be added to the backlog as a future activity?

@Brody pinging for visibility

yep i can share the procedures.

we do have this added to our backlog since you reported this, at this time you are the only one to report this issue, so as more people report this the backlogged ticket will get more traffic and we will pick it back up and move it into triage when there is a sufficient need to.