Skip to content

Conversation

@MonkeyCanCode
Copy link
Contributor

@MonkeyCanCode MonkeyCanCode commented Aug 7, 2025

Currently when running --repair with client, it will produce following message

➜  polaris git:(client_repair_mode) ./polaris --repair
Configuration on demand is an incubating feature.

> Task :regeneratePythonClient
...
Writing lock file

Installing the current project: polaris (1.0.0)
Dependencies repaired.
Traceback (most recent call last):
  File "/Users/yong/Desktop/GitHome/polaris/polaris-venv/bin/polaris", line 6, in <module>
    sys.exit(main())
             ~~~~^^
  File "/Users/yong/Desktop/GitHome/polaris/client/python/cli/polaris_cli.py", line 219, in main
    PolarisCli.execute()
    ~~~~~~~~~~~~~~~~~~^^
  File "/Users/yong/Desktop/GitHome/polaris/client/python/cli/polaris_cli.py", line 70, in execute
    client_builder = PolarisCli._get_client_builder(options)
  File "/Users/yong/Desktop/GitHome/polaris/client/python/cli/polaris_cli.py", line 175, in _get_client_builder
    raise Exception(
    ...<5 lines>...
    )
Exception: Please provide credentials via either --client-id & --client-secret or --access-token. Alternatively, you may set the environment variables CLIENT_ID & CLIENT_SECRET.

This is bad user experience as we are not expecting user to run the main CLI during repair mode. Thus. it is better to clean exit if repair mode is invoked to avoid confusion.

With this PR, we will know have following instead:

...
No dependencies to install or update

Writing lock file

Installing the current project: polaris (1.0.0)
Dependencies repaired.
➜  polaris git:(client_repair_mode) ✗

This PR also fixed a logic flaw in the first time setup complete message that will never happened with original code path.

Personally. I think using polaris bash script is very confusing for new comers as the python client is also called polaris. With the recent changes, we no longer depends on this script to invoke the client CLI. We can still use this script but maybe a diff name to setup the client as well running this repair mode.

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Aug 7, 2025
@MonkeyCanCode MonkeyCanCode merged commit 35b31ca into apache:main Aug 7, 2025
12 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Aug 7, 2025
snazy added a commit to snazy/polaris that referenced this pull request Nov 20, 2025
* fix(deps): update dependency com.nimbusds:nimbus-jose-jwt to v10.4.1 (apache#2270)

* chore(deps): update actions/download-artifact action to v5 (apache#2271)

* fix(deps): update dependency boto3 to v1.40.3 (apache#2269)

* Prefer diagnostics field in Resolver (apache#2247)

* Stop mocking PolarisDiagnostics (apache#2248)

if diagnostis checks are failing in our tests we want to know about it

* Add TestServices.newCallContext (apache#2249)

also add local `newCallContext` helper in some test classes

* Nit: simplify runtime-service dependencies (apache#2273)

Dependency "io.quarkus:quarkus-jdbc-postgresql" doesn't need any excludes (these excludes were for `SparkIT` which is now isolated in a separate module).

* Minor fixes and enhancements to External IDP documentation (apache#2274)

* Standardize logging libraries in tests (apache#2268)

This change enforces the following test logging patterns:

- Non-Quarkus modules use Logback Classic, configured via logback-test.xml
- Quarkus modules use JBoss Logging Manager, configured in Quarkus configuration files.

This change also introduces a workaround for the "duplicate log messages" issues with Gradle + JBoss Logging Manager. See this issue for context:

quarkusio/quarkus#22844

The workaround implemented in this PR is very similar to the one proposed in this comment:

quarkusio/quarkus#22844 (comment)

Note: it's not entirely possible imho to suppress the following message on the console:

```
The Agroal dependency is present but no JDBC datasources have been defined.
```

This is because:

1. The message happens during augmentation phase, not during tests
2. And it suffers from the "duplicate message" issue with (it's actually Gradle that prints those messages).

* Use Mockito Java agent for mock instrumentation (apache#2275)

This change fixes the following warning during tests:

    Mockito is currently self-attaching to enable the inline-mock-maker. This will no longer work in future releases of the JDK. Please add Mockito as an agent to your build as described in Mockito's documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org.mockito/org/mockito/Mockito.html#0.3
    WARNING: A Java agent has been loaded dynamically (.../byte-buddy-agent-1.17.5.jar)
    WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
    WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
    WARNING: Dynamic loading of agents will be disallowed by default in a future release

* Use injected PolarisDiagnostics in MetaStoreManagerFactory impls (apache#2251)

* Clean exit when running repair mode for client (apache#2287)

* Clean exit when running repair mode for client

* Clean exit when running repair mode for client

* chore(deps): update dependency poetry to v2.1.4 (apache#2259)

* chore(deps): update dependency poetry to v2.1.4

* fix pyproject

---------

Co-authored-by: Robert Stupp <snazy@snazy.de>

* fix(deps): update dependency com.gradleup.shadow:shadow-gradle-plugin to v9 (apache#2289)

* chore(deps): update docker.io/jaegertracing/all-in-one docker tag to v1.72.0 (apache#2285)

* fix(deps): update dependency boto3 to v1.40.4 (apache#2284)

* Remove PolarisCallContext.getClock (apache#2250)

the clock is application scoped and thus should not be put into any
realm or call specific context class.

* Add PolarisAdminService.loadEntities helper (apache#2261)

`PolarisAdminService` has multiple spots where it is working around the
sub-optimal `PolarisMetaStoreManager` APIs.

This results in multiple fixes like apache#1949 and apache#2258

While eventually the underlying APIs should be improved, for now we can
make a single central workaround and clean up some redundant code.
Also we can improve the return types as callers are not interested in
details of the entity layer.

* fix(deps): update dependency com.google.cloud:google-cloud-storage-bom to v2.55.0 (apache#2281)

* fix: typo in server template files. (apache#2288)

* NoSQL: merge related adoptions

* Last merged commit d753e3d

---------

Co-authored-by: Mend Renovate <bot@renovateapp.com>
Co-authored-by: Christopher Lambert <xn137@gmx.de>
Co-authored-by: Alexandre Dutra <adutra@apache.org>
Co-authored-by: Yong Zheng <yongzheng0809@gmail.com>
Co-authored-by: Yujiang Zhong <42907416+zhongyujiang@users.noreply.github.com>
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.

3 participants