Skip to content

120 update openapi python client, fix vulnerabilities, update PTB to version 5#139

Open
ckunki wants to merge 38 commits intomainfrom
refactoring/120-Update_openapi-python-client
Open

120 update openapi python client, fix vulnerabilities, update PTB to version 5#139
ckunki wants to merge 38 commits intomainfrom
refactoring/120-Update_openapi-python-client

Conversation

@ckunki
Copy link
Collaborator

@ckunki ckunki commented Feb 16, 2026

This PR closes the following issues

Closes #120
Closes #141
Closes #140

@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 07:30 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 07:32 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 07:55 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 07:59 — with GitHub Actions Inactive
Comment on lines +38 to +42
env:
SAAS_HOST: ${{ secrets.INTEGRATION_TEAM_SAAS_STAGING_HOST }}
SAAS_ACCOUNT_ID: ${{ secrets.INTEGRATION_TEAM_SAAS_STAGING_ACCOUNT_ID }}
SAAS_PAT: ${{ secrets.INTEGRATION_TEAM_SAAS_STAGING_PAT }}
PROJECT_SHORT_TAG: SAPIPY
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Manually added

@ckunki ckunki changed the title 120 update openapi python client 120 update openapi python client, fix vulnerabilities, update PTB to version 5 Feb 16, 2026
@@ -4,21 +4,24 @@ on:
workflow_call:
Copy link
Collaborator Author

@ckunki ckunki Feb 16, 2026

Choose a reason for hiding this comment

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

The workflows are mainly generated by PTB, but updated in a few places, which are commented.

Manual updated were required mainly for

  • Add secrets for accessing SaaS instances
  • Re- integrate the slow tests, which were marked with pytest.mark.slow before

Comment on lines +38 to +42
env:
SAAS_HOST: ${{ secrets.INTEGRATION_TEAM_SAAS_STAGING_HOST }}
SAAS_ACCOUNT_ID: ${{ secrets.INTEGRATION_TEAM_SAAS_STAGING_ACCOUNT_ID }}
SAAS_PAT: ${{ secrets.INTEGRATION_TEAM_SAAS_STAGING_PAT }}
PROJECT_SHORT_TAG: SAPIPY
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Manually added

@@ -1,16 +1,13 @@
from __future__ import annotations

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Main changes in this file are for handling results of type ApiError, which are new in version 0.26
of openapi-python-client.

Our updated implementation now raises an exception of type OpenApiError.

wait_fixed,
)

import exasol.saas.client.openapi.models as openapi_models
Copy link
Collaborator Author

@ckunki ckunki Feb 16, 2026

Choose a reason for hiding this comment

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

The linter coming with PTB version 5 does no longer accept

from exasol.saas.client import openapi

openapi.models.CreateDatabaseInitialCluster(...)

Copy link
Collaborator

@tkilias tkilias Feb 17, 2026

Choose a reason for hiding this comment

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

I think, we saw something similar in another project; the linter requires explicit exports if you want to import things. The explicit export can be happen by definition or by __all__

@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 09:12 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 09:17 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 10:41 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 11:15 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 16, 2026 16:42 — with GitHub Actions Inactive
@ckunki ckunki temporarily deployed to manual-approval February 17, 2026 08:20 — with GitHub Actions Inactive
Comment on lines 285 to 288
try:
return still_exists()
except (TryAgain, RetryError) as ex:
raise DatabaseDeleteTimeout from ex
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess the main reason for this change is that you can chain the original exception

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, correct. Actually, I am not 100% happy with the overall result.

I wanted to distinguish the following scenarios

  • The operation terminated successfully
  • An unexpected error happend: Should be detected and signaled ASAP without retry
  • If specific conditions are met: retry!
  • In rare use cases: ignore potential errors, in particular when deleting a database instance

Additionally I wanted to wrap unexpected errors and exceptions as well as too
many retries in an exception of a common type.

All this felt hard to me and often interfered with

  • tenacity API
  • the partially unknown behavior of the SaaS API
  • the wrapping code generated by open-api-client

I often encountered the question

  • Can a particular operation raise an exception?
    • In general probably: yes
  • Will it return a HTTP response?
    • How to map the response attributes to the scenarios described above, then?
  • Is the result of an API call of type ApiError?
    • Needs to be mapped to the scenarios described above, too.

Copy link
Collaborator

Choose a reason for hiding this comment

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

hm, the file name is a bit weird. I know it is possible with pytest, but all other places use test_*

Copy link
Collaborator Author

@ckunki ckunki Feb 18, 2026

Choose a reason for hiding this comment

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

Yes, pytest supports prefix test_ as well as suffix _test.py.
Bucketfs-python is inconsistent, as well, for example.
I don't have a clear opinion here.

  • If working on an implementation, then it makes sense to separate production code from tests using the prefix.
  • If opening a specific test, then the common prefix test_ feels redundant, as the test files are in directory test/ anyway.
  • In notebook-connector, I tried prefixes itest_ and utest_ which I found helpful.

I renamed the files in SAPIPY now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

hm, the file name is a bit weird. I know it is possible with pytest, but all other places use test_*

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I renamed the files in SAPIPY now.

@ckunki ckunki temporarily deployed to manual-approval February 18, 2026 10:23 — with GitHub Actions Inactive
@sonarqubecloud
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
77.5% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

if still_exists():
raise DatabaseDeleteTimeout
try:
return still_exists()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
return still_exists()
still_exists()

@ckunki ckunki deployed to manual-approval February 19, 2026 14:09 — with GitHub Actions Active
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants

Comments