The reason primary fragment exists in the first place is for the SEO (to generate a valid status code of the page) and not send 200/500 all the time to the client.

I am not sure how will you deal with status codes when two fragments have influence on the page, do you still mean to keep primary and introduce the obligatory attribute?

The way we deal with this problem is to have a fallback-src attribute for the fragment, which can still render a usable page with most of the functionality.

do you still mean to keep primary and introduce the obligatory attribute?

Yes.

The way we deal with this problem is to have a fallback-src attribute for the fragment, which can still render a usable page with most of the functionality.

Let's say the fallback-src also fails. Tailor currently will ignore it, thats where obligatory comes in, makes sure to raise an error so that we can act accordingly.

@shilangyu yeah got it, raise an error in the sense of returning 500 page?

500 sounds good, would the tailor.on('error', () => {}) be called after such error?

After having some thought process, I started to feel like this would mean we have to hold on to the response stream till all the obligatory fragments respond (normal src and also fallback-src) which will have a huge performance impact on time to first byte time.