Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid HTTP response 503 from https://tx.dev.hl7.org.au #192

Open
dattachandan opened this issue Aug 9, 2024 · 11 comments
Open

Invalid HTTP response 503 from https://tx.dev.hl7.org.au #192

dattachandan opened this issue Aug 9, 2024 · 11 comments
Assignees

Comments

@dattachandan
Copy link

Hi team

When I ran the container locally(can't see on the remote sever on Cloudwatch), I see exceptions during validation , are these intermittent and is there a way to run the TX server locally?

image

Attaching a sample log below

httpResultException-503-fhir-TX.log

@projkov
Copy link
Collaborator

projkov commented Aug 15, 2024

Hello Chandan @dattachandan

It looks like there was a temporary problem with the accessibility of the terminology server. Now it should work without any issues.

Unfortunately, we don't have the option to run the TX server locally.

I appreciate your interest in our test kit!

@projkov projkov self-assigned this Aug 15, 2024
@projkov
Copy link
Collaborator

projkov commented Aug 15, 2024

@dattachandan Users can set any TX server URL using a variable called TX_SERVER_URL. By default value is https://tx.dev.hl7.org.au/fhir

@projkov
Copy link
Collaborator

projkov commented Aug 15, 2024

@mjosborne1

Hello Michael. Is there any way to run the ontoserver locally?

@dattachandan
Copy link
Author

@projkov thanks for the update, will be good to know if a AU based terminologies server can be set locally especially when we do internal CI builds for any integration testing

@lawley
Copy link

lawley commented Aug 21, 2024

I don't know that running a local Ontoserver will help with the above.
The request with the error is to a non-FHIR, Grahame-specific endpoint (.../tx-reg/...). This looks more like a bug in the validator

@lawley
Copy link

lawley commented Aug 22, 2024

Looking at the code in org.hl7. fhir.r5. terminologies .client. TerminologyClientManager it seems that setting IGNORE_TX_REGISTRY=true should avoid any attempt to use the tx registry

@ir4y
Copy link
Collaborator

ir4y commented Aug 23, 2024

@projkov please have a look and test ☝️

@projkov
Copy link
Collaborator

projkov commented Aug 29, 2024

Looking at the code in org.hl7. fhir.r5. terminologies .client. TerminologyClientManager it seems that setting IGNORE_TX_REGISTRY=true should avoid any attempt to use the tx registry

@lawley Hello Michael. Thank you for the advice.

Did you know something about how to change the value of this variable through cliContext? I can't find any information in the docs, or code samples.

@ir4y
Copy link
Collaborator

ir4y commented Sep 16, 2024

@ir4y ir4y assigned ir4y and unassigned projkov Sep 16, 2024
@jwjahns
Copy link

jwjahns commented Oct 17, 2024

Hello, I also ran into this when attempting to deploy locally, and found that setting noEcosystem true in the cli_context blocks (here and here) seems to resolve this. In the Java validator code, noEcosystem eventually sets useEcosystem, which is checked in the same places that IGNORE_TX_REGISTRY is checked. However, I couldn't find documentation on this noEcosystem parameter, so I'm not entirely sure if this is the intended usage.

(note that this requires a Java validator version of at least 6.3.6 - see "Dont use tx-registry when manual terminology server is set")

@ir4y
Copy link
Collaborator

ir4y commented Oct 17, 2024

@projkov Could you please check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants