You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
every upload, download, and metadata operation requires a workflow ID
provider behavior moves into package-private S3, Azure, GCS, local, and generic HTTP transfer adapters
signed transfers use an isolated raw OkHttp client with redirects, cookies, auth, and interceptors disabled
multipart selection is automatic; S3 validates ETags and Azure uses stable block IDs
stream uploads are repeatable and do not close caller-owned streams
downloads use sibling temporary files and atomic replacement
retries refresh signed URLs, reconcile ambiguous completion, and preserve interruption
removes smart file objects and automatic TaskRunner upload/download integration
adds complete API, design, migration, and media-transcoder examples
Breaking change: workers now exchange raw handle strings and invoke FileClient explicitly. Workflows using {fileHandleId, fileName, contentType} objects need a coordinated worker rollout.
Keeping provider backends as a public extension point would expose signed-URL protocol details and split retry/lifecycle ownership. Keeping smart file objects would continue coupling worker serialization and TaskRunner behavior to storage, so both were replaced with explicit handle strings and FileClient calls.
Follow-up cleanup: audited io.orkes.conductor.client.model.agent and removed redundant @JsonProperty annotations. Explicit mappings remain only for genuine wire-name differences (static_plan, snake_case tool fields, and is... status booleans) plus the write-only RespondBody fields that require explicit Jackson visibility. Added focused serialization/deserialization and alias tests; agent model tests, OrkesAgentClientTest, and Spotless all pass.
Converted all six io.orkes.conductor.client.model.agent DTOs to Lombok @Data and removed handwritten getters, setters, and toString methods. RespondBody.extraFields now uses Lombok @Getter(onMethod_ = @JsonAnyGetter), and null-to-empty response collections retain their behavior via @JsonSetter(nulls = Nulls.AS_EMPTY). JSON contract tests, OrkesAgentClientTest, and compilation pass.
Live validation against http://localhost:8080/api completed successfully at pushed commit dbc6fb84:
Agent E2E: serialized AgentRequest, deserialized StartResponse, polled AgentStatusResponse to COMPLETED, and verified LIVE_OK; temporary agent definition was deleted.
FileClient E2E: media_transcode completed with stream upload, annotated workers, parallel downloads/uploads, metadata reads, and four opaque conductor://file/... outputs.
Artifact verification: focused agent tests, Javadocs, shaded JAR, and publishToMavenLocal all pass.
Validation found and fixed one publication-only issue: Lombok onMethod_ compiled but broke Javadoc. RespondBody.extraFields now uses field-level @JsonAnyGetter with @Getter(AccessLevel.NONE), preserving flattened JSON without duplicate extraFields output.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request type
Changes in this PR
Depends on conductor-oss/conductor#1355 for the workflow-scoped File API.
Simplifies the public file API around one explicit, workflow-aware
FileClient:conductor://file/<id>stringsBreaking change: workers now exchange raw handle strings and invoke
FileClientexplicitly. Workflows using{fileHandleId, fileName, contentType}objects need a coordinated worker rollout.Issue #
Tests
./gradlew :conductor-client:test --tests org.conductoross.conductor.client.FileClientTest --tests org.conductoross.conductor.client.FileTransferAdaptersTest --tests org.conductoross.conductor.client.FileClientPropertiesTest :conductor-client-spring:test --tests com.netflix.conductor.client.spring.ConductorClientAutoConfigurationTest./gradlew :conductor-client:spotlessJavaApply :conductor-client-spring:spotlessJavaApplyAlternatives considered
Keeping provider backends as a public extension point would expose signed-URL protocol details and split retry/lifecycle ownership. Keeping smart file objects would continue coupling worker serialization and TaskRunner behavior to storage, so both were replaced with explicit handle strings and
FileClientcalls.