You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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.
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:
is verify that the production URL is correct
Figure out if this is actually running in TEST (do we know?)
Coordinate with Sarah to get it deployed to production
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?
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.
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.
Activity
saramsey commentedon Oct 8, 2026
@bazarkua can you look into this?
bazarkua commentedon Oct 8, 2026
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 callsnodenorm-es.test.transltr.ioand PROD callsnodenorm-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 toname-resolution-sri.renci.orgon all branches, so it needs the same kind of map.edeutsch commentedon Oct 9, 2026
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:
current state of
test-itrb:https://github.com/RTXteam/RTX/blob/itrb-test/code/ARAX/NodeSynonymizer/node_synonymizer.py
thank you!
bazarkua commentedon Oct 9, 2026
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?
edeutsch commentedon Oct 9, 2026
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.
#2913 log the resolved Name Resolver URL, not the RENCI fallback cons…
Merge pull request #2917 from RTXteam/itrb-test-hotfix-20261009
edeutsch commentedon Oct 19, 2026
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.