Skip to content

[916] Correct three inaccuracies in the REST service spec - #917

Open
slachiewicz wants to merge 1 commit into
apache:mainfrom
slachiewicz:spec-accuracy
Open

[916] Correct three inaccuracies in the REST service spec#917
slachiewicz wants to merge 1 commit into
apache:mainfrom
slachiewicz:spec-accuracy

Conversation

@slachiewicz

Copy link
Copy Markdown
Member

What is the purpose of the pull request

Closes #916. Three places where rest-service-open-api.yaml describes something other than what
xtable-service does. The first is the one worth reviewing: a client that follows the spec as
published sends a request the service rejects.

Brief change log

  • Added source-data-path to ConvertTableRequest, as required. ConversionService passes it to
    TargetTable.basePath, which ExternalTable declares @NonNull, with no fallback -- so the four
    documented required fields are not a valid request. A request that follows the published REST spec fails: source-data-path is required but undocumented #916 covers the alternative fix, defaulting
    it in ConversionService; this PR takes the spec-only route.
  • Narrowed the configurations description. Only partition-spec is read
    (ConversionService.java:195); every other key is discarded. It no longer advertises itself as a
    place for storage credentials, which the service does not read from there and which a request body
    should not carry -- bodies are logged, traced and cached.
  • Dropped ErrorModel.stack. Nothing populates it: there is no ErrorModel class and no
    ExceptionMapper in the module. Removing it now is cheaper than removing a stack trace that
    someone has since implemented.
  • Bumped info.version to 0.0.2, since a newly required request field and a removed response field
    are both contract changes. Happy to drop this hunk if you version the spec on a different cadence.

Verify this pull request

This pull request is a trivial rework / code cleanup without any test coverage.

cd spec && make lintrest-service-open-api.yaml: OK. No Java file is touched, so behaviour is
unchanged; what changes is whether the contract matches it.


This change was created with AI assistance.

source-data-path was absent from ConvertTableRequest although the service reads
it. It is not optional: ConversionService passes it to TargetTable.basePath,
which ExternalTable declares @nonnull, with no fallback, so a request that omits
it fails. Every test sets it, which is why the gap survived. Documenting it as
required matches the service as written; defaulting it to source-table-path in
ConversionService would be the other way to close this, and is a maintainer call.

configurations claimed to carry storage credentials. Only "partition-spec" is
read; every other key is discarded. The service authenticates to cloud storage
from its own environment, and a request body is logged, traced and cached, so
the description now says credentials do not belong there.

ErrorModel.stack offered stack traces to callers. Nothing populates it -- there
is no ErrorModel class and no ExceptionMapper -- and a stack trace in a public
response schema is an information leak, so it is dropped rather than left as a
standing invitation to implement.

info.version moves to 0.0.2, since a required request field and a removed
response field are both contract changes.

Verified: cd spec && make lint -> rest-service-open-api.yaml: OK.
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.

A request that follows the published REST spec fails: source-data-path is required but undocumented

1 participant