Skip to content

Need to remove hard-coded service URLs #2913

Closed

Description

@edeutsch

During today's PROD deployment, it was discovered that ARAX hard-codes some services by URL, e.g.:

NODE_NORMALIZER_URL = "https://nodenorm-es.ci.transltr.io"
NAME_RESOLVER_URL = "https://name-resolution-sri.renci.org"

This means that our ITRB TEST server was using these instances, and that our PROD server will be using these, whereas we should be using the appropriate server for the current maturity.

This probably should happen via SmartAPI entries (and another mechanism is possible).
However, today the SmartAPI entries are not yet in place. But Gaurav says that they will be shortly.

This is an emergency fix that should go through CI -> TEST -> PROD as soon as possible. Although the exact timeline for that isn't quite clear to me.

We should also sweep the code for other occurrences of this! There may be more.

Activity

  1. saramsey commented on Oct 8, 2026

    @saramsey
    Member

    @bazarkua can you look into this?

  2. bazarkua commented on Oct 8, 2026

    @bazarkua
    Collaborator

    Some background on how this happened for NodeNorm

    In May we moved NodeSynonymizer from a local database to the SRI APIs (#2730), and we hardcoded the URLs on purpose. We wanted this file to have no dependency on ARAX config, so other projects like Pathfinder can use it as a separate package (and the CI endpoint was the most stable). In July NodeNorm moved to ElasticSearch with a short deadline, so we pointed it to the CI ElasticSearch server (#2833).

    On 9/16 we added selection by maturity: a map from maturity to NodeNorm URL and resolve_node_normalizer_url(), so TEST uses the TEST NodeNorm. This change is in master and itrb-test. But the production branch was made from the 9/08 tag, which is older than this change (see production...itrb-test). So PROD got the old code with only the CI URL, and now calls the CI NodeNorm, while TEST calls the TEST one. Today's query logs show this: TEST calls nodenorm-es.test.transltr.io and PROD calls nodenorm-es.ci.transltr.io.

    The fix for NodeNorm is small: bring the 9/16 change to production and change the production entry to https://nodenorm-es.transltr.io, which is up and answers correctly now. NameRes is different: it is still hardcoded to name-resolution-sri.renci.org on all branches, so it needs the same kind of map.

  3. edeutsch commented on Oct 9, 2026

    @edeutsch
    CollaboratorAuthor

    Very good, thanks for clarifying all this. I should have migrated these changes to production, but did not realize that there were changes since my last tag. I think what is left to do:

    1. is verify that the production URL is correct
    2. Figure out if this is actually running in TEST (do we know?)
    3. Coordinate with Sarah to get it deployed to production

    current state of test-itrb:
    https://github.com/RTXteam/RTX/blob/itrb-test/code/ARAX/NodeSynonymizer/node_synonymizer.py

    thank you!

  4. bazarkua commented on Oct 9, 2026

    @bazarkua
    Collaborator

    Sounds good! will do. Just to clarify by 3. do you mean deploying to production the timeline as I understand to push it to the next deployment (following week after so next Thursday after code freeze is lift off) or try to push these changes to the PROD tomorrow?

  5. edeutsch commented on Oct 9, 2026

    @edeutsch
    CollaboratorAuthor

    I am uncertain. I got the impression that another push to PROD next week Thursday was possible if we orchestrate things correctly. I do not know if Sarah wants to try that. If not, then I guess it goes in with the next batch later in October. At which point we could switch to SmartAPI based URLs instead of hard-coded.

  6. added 2 commits that reference this issue on Oct 9, 2026
  7. edeutsch commented on Oct 19, 2026

    @edeutsch
    CollaboratorAuthor

    These fixes are running in TEST and will be deployed to PROD so I guess this is fine.
    It seem not so great that all URLs are written into the code.
    It would be better to get them from SmartAPI. But SmartAPI records continue to be a mess and are not usable
    Other teams are using helm charts to encode this information.
    Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions