N/A

The build queue is dependant on whether the service refers another service's variable
if for example backend references MYSQL_URL from mysql then it'll wait until mysql finishes building before backend starts building

this is from a [recent changelog]()

Although in this case, without altering the reference variables, I'm not sure you can do anything to directly alter the queues; I agree I feel like there should be a bit more customizability with queues and how they happen

Thanks for the explanation. In that case I can't do much, they are both depending on values from each other 🤔

@Fragly
I think I need to escalade this issue, it is actually more severe than first thought, Im currently stuck with this template. after 20 minutes the storefont timeoud out, as it was not able to receive API key from backend, that was (still is) queued waiting for the storefront.

Project ID: 3d6ece5e-fa0c-4d26-9eae-82fd525505e8

I have another similar template with the same setup.

Build fiailing due to new queue dependency order

Build fiailing due to new Control Service Startup Order

why is the bucket taking 20 minutes to deploy?

I don't know. Last time I used to template, it took 2-3 minutes.

I'm also seeing unusual deploy behavior on other templates. Postgres database took 4 minutes to deploy (usually takes few seconds) so nextJS app failed during build unable to connect to postgres. I didn't configure any advance wait logic because this did not use to be necerssary.

But I am more concerned with this more complex medusa template. there's quite a few people using it

project id please

eb5f3972-1306-46e5-8974-a2290b45e157

I restarted the build though. So the nextjs app is running now. but it failed initially

looks like the storefront crashed because the backend crashed?

The backend did crash yes. But the storefront timeout before the backend even started building. because the backend was queued

is this reproducible?

I can launch the template a few times - and see how many of them will get into this build state. But 2/2 times, the queue order was troublesome. and in 1/2 cases did it actually timeout after 20 minutes. The other case, the queueing was relieved before timeout, but the build time was still longer than twice of the normal build time, due to the backed being on hold for 5 minutes

Fresh launch:
1cc844be-d7a5-4421-8d6f-33526822f8ea
94575bbf-58b8-427c-9338-4659e9e13065

building should not be halted, only deploys

oh you are depending on the backend during build

yes, they need to be sharing a number of things, the backend needs to expose an API key that the storefront needs for communicating with the standard API of the backend. The storefron can only build, if it can fetch products data, used to create static pages.

So in this case, I don't see how I can do it differently

both of them need the other ones public url for comm CORS whitelisting

you wouldnt want to do that during build in this case

do it during runtime

Im afrid that's not something I can change easily. The documentation of the storefront app states that it needs the api key in order to run the next build script.

where is the api key stored

It is generated, by the backend, once the backend has completed build and initial seeding

This is not my design, this is just how the medusa stack works. this was introduced a few montsh ago

im not seeing any issues in running the storefront build during runtime

I'm not really sure I undersatnd what you are suggesting. Doing nothing in the build step, and then run the nextjs build app compilation in runtime?

This is still not working.

The backend is still queued, while the storefront has passed the build phase.

2ef7662b-2980-4632-aba5-c1b992b59819

Unfortunately, I have to leave. So I can't perform any other experiments for now. I'll unpublish the template to prevent users from launching it in a broken state.

Good morning! 🌞
So I tried what I believe is what you suggested, not compiling the storefront app in the build phase, but moving that part to runtime:

"build": "echo 'skipping build stage'",
"start": "npm run wait && npm run launcher build && npm run launcher start",

The wait is pinging the backend until it receveis a positive response - then the app compilation (launcher build) can take place, as it is dependent on the backend. And finally if build is completed then starting the app launcher start.

As the screenshot above indicates, though the storefront passed the build step pretty quickly, the backend remained queued, with the message "waiting for dependencies to deploy". - (ideally it should be the other way around)

I don't really see any way forward at this point, so I need some help to get this to work…. The new deploy order, makes a clever guess which services depend on which, based on how variables are shared between them. In my case, both services needs a value from the other, the storefront needs the public url from the backend in order to know the api, and the backend requires knowing the public domain of the storefront in order to accept api requests (CORS whitelisting). So I don't think it is possible removing any of these variables to change the guessed dependency order. I also don't see any easy way to make the storefront "finish" before the backend, in theory, I could open a endpoint to use for healthcheck before wait then the backend could start - but then Railway would indicate to the user that the storefront is ready and expose its url, before the app has even started compiling. I think this would be too hacky and confusing, not really an acceptable UX.

Any suggestions?

I'll ask the creator of this feature monday

Any news on this by any chance? I'm struggling to deploy.

postgres waiting for very long for some reason. Some time backend goes into building, then it goes back into queue. And most of the times build fails due to storefront timeout after 20 minutes.

Prior to this new deploy order logic, the entire project would build in about 5-7 minutes.

sorry, haven't had time to take this up with him yet

No worries! I will check back in a day or two

Good news, in the cases like this where you have a cyclic dependency, we will now simply deploy both at the same time

Fantastic! Those templates now deploy at lights speed again, and without failing 😁

awesome!

!s