fix(ApiWeb): set compile-time variable for stop_events_route

[runkelcorey]

Summary of changes

1. Remove feature flag for stop events endpoints, exposing stop events to API requests
2. Remove references to said feature flag
3. Mark stop_events as experimental

Background

Asana Ticket: 📸↩︎ construct database query (ApiWeb.StopEventController + ApiWeb.StopEventView.location + router)

#987 failed to deploy to dev and dev-blue. Splunk showed

ERROR! the application :api_web has a different value set for path [:stop_events_route]
inside key :features during runtime compared to compile time. Since this application
environment entry was marked as compile time, this difference can lead to different
behavior than expected

1. I didn't realize that mix would check for compile-time values as well as runtime
2. I assumed that dev compiled with dev as MIX_ENV but it actually uses PROD

How were these changes validated?

1. Successfully deployed to dev-green

[lemald]

question: is the idea that we want to be able to set the application environment variable at runtime to enable / disable the feature, not just at compile time? If so, then the use of Application.compile_env will have to change. In any event, if I understand correctly, the STOP_EVENTS_ROUTE environment variable could be set differently on the prod environment versus where the application gets built, which would surface this error again.

[runkelcorey]

question: is the idea that we want to be able to set the application environment variable at runtime to enable / disable the feature, not just at compile time?

Yes. For example, I would like dev-green to use true for STOP_EVENTS_ROUTE, while prod uses false. This would let us see and use the stop_events route for testing without exposing that route and its docs to the prod API.

If so, then the use of Application.compile_env will have to change. In any event, if I understand correctly, the STOP_EVENTS_ROUTE environment variable could be set differently on the prod environment versus where the application gets built, which would surface this error again.

Are the environment variables not available to the GH Action task builds the application?

[lemald]

Are the environment variables not available to the GH Action task builds the application?

There are environment variables available to the GH Action task, but those are different from the environment variables available in the container. We could of course manually keep them in sync, but they're not actually the same thing.

[runkelcorey]

@lemald how about this? let all the modules compile, and expose StopEvents as an available path, but—lacking a native experimental or unstable tag—change the summary to experimental with clear docs saying that it will return nothing

[lemald]

@lemald how about this? let all the modules compile, and expose StopEvents as an available path, but—lacking a native experimental or unstable tag—change the summary to experimental with clear docs saying that it will return nothing

Hmm, this is better but I still don't love it... unfortunately because of the compile-time nature of a lot of the stuff involved via macros it's a little bit hard to make a good feature flag for it. Let me sleep on this and revisit tomorrow morning.

[lemald]

I think this is the best approach we're likely to get. Let's try to get the remaining work out the door relatively promptly so that prod isn't in this state for long.

[runkelcorey]

@lemald I spent a good chunk of yesterday trying to find a better solution but...compiled languages + if-else macros, man! this approach seemed the least risky