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

Async issues in tests #303

Open
jsstevenson opened this issue Aug 6, 2024 · 6 comments
Open

Async issues in tests #303

jsstevenson opened this issue Aug 6, 2024 · 6 comments
Labels
bug Something isn't working priority:high High priority

Comments

@jsstevenson
Copy link
Member

Describe the bug

Running the constructor tests yields an assortment of errors related to asynchronous initialization of and access to FUSOR resources. This is bad.

Steps to reproduce

pytest tests/integration/test_constructors.py

Expected behavior

They should pass, or at least fail by value

Current behavior

Instead they produce a lot of varying async-related errors, particularly if you only call one at a time.

Possible reason(s)

No response

Suggested fix

No response

Branch, commit, and/or version

staging branch

Screenshots

No response

Environment details

mac

Additional details

No response

Contribution

Yes, I can create a PR for this fix.

@jsstevenson jsstevenson added bug Something isn't working priority:high High priority labels Aug 6, 2024
@jsstevenson
Copy link
Member Author

Also -- double check these values in test_complete_gene:

    # TODO these aren't matching anymore, and the results here look kind of weird.
    # we should double check in a separate issue
    # assert response_json["prev_symbols"] == [
    #     ["A", "LOC100420587", "ncbigene:100420587", "NCBI:NC_000019.10", "-"]
    # ]
    # assert response_json["aliases"] == [
    #     ["A", "LOC110467529", "ncbigene:110467529", "NCBI:NC_000021.9", "+"]
    # ]

@jsstevenson
Copy link
Member Author

And -- rather than checking exact values in test_complete_domain, have an example of some canonically important domain to check for

Copy link

github-actions bot commented Nov 6, 2024

This issue is stale because it has been open 90 days with no activity. This issue will be closed if no further activity occurs in 14 days.

@github-actions github-actions bot added the stale label Nov 6, 2024
@jsstevenson jsstevenson removed the stale label Nov 6, 2024
@jsstevenson
Copy link
Member Author

@jarbesfeld as the last person to run tests on this code -- is this still happening? does your PR fix it by including the event loop fixture?

@jarbesfeld
Copy link
Contributor

@jsstevenson I haven't tested this out yet for fusion-curation

@jsstevenson
Copy link
Member Author

@jarbesfeld sorry, pre-coffee moment, ignore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority:high High priority
Projects
None yet
Development

No branches or pull requests

2 participants