Gateway time-out when opening a long relation history

[gy-mate]

URL

https://www.openstreetmap.org/relation/7795942/history

How to reproduce the issue?

1. Open the URL
2. See the following error:
   

Screenshot(s) or anything else?

This relation is enormous: it has 275 members and 94 versions. But the website could handle these cases somehow (error handling / longer timeout / splitting versions to several pages), I think, considering that the relation of the Hungarian railway line 1 has more members and might also reach this version size in the near future: https://www.openstreetmap.org/relation/11965670

[tomhughes]

We do have a timeout but it looks like it's actually too long because cloudflare times out first. As far as I know we have no control over the cloudflare timeout but in any case that's an operational issue relating to the production deployment and not an issue with the web site code.

[Firefishy]

Cloudflare timeout is 100 seconds and we are unable to change it in the edition we are using.

[gy-mate]

@Firefishy For me it times out in just 30 seconds, not 100.

[AntonKhorev]

Maybe Cloudflare decides to display their timeout page when it receives a timeout status code from osm-website?

[gy-mate]

Cloudflare timeout is 100 seconds and we are unable to change it in the edition we are using.

@Firefishy For me it still times out in just 30 seconds, not 100.

[tomhughes]

Which is the duration of the upstream timeout so I guess that is firing but cloudflare is replacing the rails error with it's own.

[gy-mate]

I see. Would dividing the versions loaded on the relation history page into pages of, for instance, 20, resolve this issue? (So that the PostgreSQL query would be sped up with LIMIT and OFFSET.)

https://www.openstreetmap.org/relation/11965670/history is also getting close to the timeout: currently it loads in ~25 seconds.