Skip to content

Gemini Changes - #249

Merged
moonraker595 merged 97 commits into
mainfrom
Adding-strings-to-model
Sep 16, 2026
Merged

moonraker595 merged 97 commits into
mainfrom
Adding-strings-to-model

Conversation

@moonraker595

@moonraker595 moonraker595 commented Apr 13, 2026 •

Copy link
Copy Markdown
Contributor

This PR:

  1. Adds string as a new data type:
    Introduces string as a supported data type.

  2. Allows string for shotnum field:
    Updates the shotnum field to accept both int and string values.
    Maintains backward compatibility with existing numeric shot numbers.

  3. Add an optional type field to shotnum:
    Introduces an optional type attribute to the model for shotnum datatype.
    If type is not provided, the system infers the type based on the value (str or int).

  4. Support sub-second timestamp ingestion:
    Extends ingestion logic to handle timestamps with sub-second precision.

  5. Enhancements to range converter:
    Updates range conversion logic to correctly handle mixed shotnum types (int and string).

  6. Clean up:
    Adds a new lock file for dependency updates (which is the bulk of the reported line changes)

@moonraker595 moonraker595 changed the title Adding strings to model Adding strings and timestamps Apr 14, 2026
@codecov

codecov Bot commented Apr 14, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 90.17544% with 28 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.47%. Comparing base (9381719) to head (5675c30).

Files with missing lines Patch % Lines
...nsgateway_api/src/records/ingestion/hdf_handler.py 81.25% 4 Missing and 5 partials ⚠️
...perationsgateway_api/src/records/export_handler.py 76.47% 3 Missing and 5 partials ⚠️
operationsgateway_api/src/records/record.py 45.45% 3 Missing and 3 partials ⚠️
operationsgateway_api/src/routes/auth.py 66.66% 2 Missing and 1 partial ⚠️
...gateway_api/src/records/ingestion/record_checks.py 0.00% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #249      +/-   ##
==========================================
- Coverage   96.88%   96.47%   -0.41%     
==========================================
  Files          88       88              
  Lines        4944     5164     +220     
  Branches      439      488      +49     
==========================================
+ Hits         4790     4982     +192     
- Misses        103      119      +16     
- Partials       51       63      +12     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@moonraker595

Copy link
Copy Markdown
Contributor Author

I've beefed up the test coverage. Fair warning; the last of the auth ones and all of the user ones were AI generated via co-pilot. I think it's in a much better place now, I'll ping it back over to you.

@moonraker595

Copy link
Copy Markdown
Contributor Author

oh one thing I haven't actually done yet is test all the export stuff (post-merge) via Postman. I'll do that first thing tomorrow.

@moonraker595

Copy link
Copy Markdown
Contributor Author

oh one thing I haven't actually done yet is test all the export stuff (post-merge) via Postman. I'll do that first thing tomorrow.

I've checked this manually, and all works as expected. Just didn't want to rely solely on the automated test is all.

@moonraker595

Copy link
Copy Markdown
Contributor Author

ebc0b76: noticed a logging issue in which string and scaler values were falling through the if statement, this meant 1000's of duplicated logging lines. This just makes things more explicit.

@patrick-austin patrick-austin left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a look over it again and could only find one (very) minor formatting change I'd definitely make (test_get_crosshair_intensity.py).

The rest are things that I noticed and wanted to check you're happy with, but in principle I don't think necessarily need to change if you are. As far as I could see the codecov report is OK given that we won't have the Gemini suite contributing to the coverage (I didn't consider on my last review until you pointed it out). I've left some thoughts about that as well but think it would be fine to let it lie (either for this PR and pick up as a separate issue, or for the foreseeable future).

One final thing - I was asking Kevin what bits of the API code would be covered by the "data integrity" testing he's been doing and if he knew what version/commit the Gemini instance is running, since I wasn't sure if any changes made to this branch would affect things for him. I think the answer was essentially "no" since he wasn't using export, and I guess at some point we'd have to deploy the latest version of the API to the Gemini instance anyway so it would get tested in pre-prod whenever that happens.

Comment thread operationsgateway_api/src/auth/authentication.py Outdated
Comment thread operationsgateway_api/src/auth/authentication.py Outdated
Comment thread operationsgateway_api/src/auth/authentication.py Outdated
Comment thread operationsgateway_api/src/auth/authentication.py Outdated
Comment thread operationsgateway_api/src/auth/authentication.py
Comment thread operationsgateway_api/src/auth/authentication.py Outdated
Comment thread operationsgateway_api/src/records/ingestion/channel_checks.py Outdated
Comment thread operationsgateway_api/src/records/ingestion/channel_checks.py Outdated
Comment thread .github/workflows/ci.yml
Comment thread test/endpoints/test_get_crosshair_intensity.py Outdated
@moonraker595

moonraker595 commented Sep 15, 2026 •

Copy link
Copy Markdown
Contributor Author

Thanks, have made the appropriate changes.

With regards to Kevin's testing; As you mentioned, he is only testing the data, not the version/functionality of OG.
The version deployed to prod (there is no pre-prod) is commit 09f295d58d7e270758650a3556acf28d903ad115 which is from July 23rd and holds most of the UO functionality used for testing with Louise. Once this is commited into main i need to come up with a release plan which will entail:
1st: Gemini and test
2nd: Epac pre-prod and test, then prod
3rd: Clara, using it as a new base for pre-prod and prod (there's nothing on prod at the mo, so it needs setting up)

@patrick-austin patrick-austin left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good - just had one comment about the custom validator for the user office config. I think it's fine as is but was wondering if an optional "sub-model" would let us get the same functionality without having to write/test a custom validator? If there's a reason I'm missing why that wouldn't work, or you've already considered it and prefer it this way then I'm happy to approve, but thought it was worth raising for consideration at least.

Comment thread operationsgateway_api/src/config.py Outdated
Comment on lines +121 to +139
@model_validator(mode="after")
def check_user_office_settings(self) -> "AuthConfig":
"""
When the User Office integration is enabled, both the API key and the users
service URL are needed to contact it
"""
if self.user_office_integration:
missing = [
name
for name in ("user_office_api_key", "user_office_users_service_url")
if not getattr(self, name)
]
if missing:
raise ValueError(
f"{', '.join(missing)} must be set when "
"'user_office_integration' is enabled",
)

return self

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative way of doing this could be to define an optional UserOfficeConfig that is optional in the main config, but with both the API key and url being required within the model itself. That would mean we don't need custom validation since Pydantic will allow nothing to be provided (i.e. user_office_config=None) or both, but if only one is provided then `UserOfficeConfig is missing a required field and it will fail.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. There are a few files changed, but they're mostly single-line changes. I had forgotten we could check on the empty tag, and we do this elsewhere, so this is a lot neater. Good catch.

@moonraker595

Copy link
Copy Markdown
Contributor Author

I initially assumed a sub-model would require moving the User Office settings out of the auth section, but I suppose it can be an optional nested model within AuthConfig, so a sub sub model. So the config would look like:

auth:
  refresh_token_validity_days: ...
  fedid_server_url: ....
  fedid_server_ldap_realm: ....

  user_office:
    api_key: ...
    users_service_url: ...

So the user office section is optional, and other deployments just won't have. Sound ok?

@moonraker595
moonraker595 merged commit 57c808f into main Sep 16, 2026
7 checks passed
@moonraker595
moonraker595 deleted the Adding-strings-to-model branch September 16, 2026 14:07
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

Successfully merging this pull request may close these issues.

2 participants