Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] WorkflowRequest doesn't serialize the use case and default parameters over transport #758

Closed
dbwiddis opened this issue Jul 4, 2024 · 1 comment · Fixed by #952
Assignees
Labels
bug Something isn't working v2.19.0

Comments

@dbwiddis
Copy link
Member

dbwiddis commented Jul 4, 2024

What is the bug?

The WorkflowRequest class doesn't serialize the use case and default parameters over transport.

The writeTo() only writes the provision parameter and params map:

public void writeTo(StreamOutput out) throws IOException {
super.writeTo(out);
out.writeOptionalString(workflowId);
out.writeOptionalString(template == null ? null : template.toJson());
out.writeStringArray(validation);
out.writeBoolean(provision);
if (provision) {
out.writeMap(params, StreamOutput::writeString, StreamOutput::writeString);
}
}

Similarly, the constructor using StreamInput doesn't read them

public WorkflowRequest(StreamInput in) throws IOException {
super(in);
this.workflowId = in.readOptionalString();
String templateJson = in.readOptionalString();
this.template = templateJson == null ? null : Template.parse(templateJson);
this.validation = in.readStringArray();
this.provision = in.readBoolean();
this.params = this.provision ? in.readMap(StreamInput::readString, StreamInput::readString) : Collections.emptyMap();
}

This was missed in unit testing because the tests incorrectly checked the original workflowRequest and not the streamInputRequest after passing through transport. (Note the last 4 lines.)

BytesStreamOutput out = new BytesStreamOutput();
workflowRequest.writeTo(out);
BytesStreamInput in = new BytesStreamInput(BytesReference.toBytes(out.bytes()));
WorkflowRequest streamInputRequest = new WorkflowRequest(in);
assertEquals(workflowRequest.getWorkflowId(), streamInputRequest.getWorkflowId());
assertEquals(workflowRequest.getTemplate().toString(), streamInputRequest.getTemplate().toString());
assertNull(workflowRequest.validate());
assertFalse(workflowRequest.isProvision());
assertTrue(workflowRequest.getDefaultParams().isEmpty());
assertEquals(workflowRequest.getUseCase(), "cohere-embedding_model_deploy");

How can one reproduce the bug?

Fix the unit test to properly test the workflow created from transport. Change lines 163-166 above to:

        assertNull(streamInputRequest.validate());
        assertFalse(streamInputRequest.isProvision());
        // FAILS, `getDefaultParams()` is null
        assertTrue(streamInputRequest.getDefaultParams().isEmpty()); 
        // FAILS, `getUseCase()` is null
        assertEquals(streamInputRequest.getUseCase(), "cohere-embedding_model_deploy");

What is the expected behavior?

If these fields are required to be part of the WorkflowRequest they should be properly serialized. Note that adding these fields would break compatibility across versions and would require version-checking for the additional fields.

However, these fields are never accessed in the code, other than in the (failing) tests. If they are not needed, they should be removed.

Do you have any additional context?

The fields were added in #583.

The tests have been fixed in #757, with the failing tests commented out until this issue is resolved.

@dbwiddis dbwiddis added bug Something isn't working untriaged v2.16.0 Issues targeting release v2.16.0 labels Jul 4, 2024
@dbwiddis dbwiddis removed the untriaged label Jul 4, 2024
@dbwiddis dbwiddis added backlog Good to have functionality not critical for next release and removed v2.16.0 Issues targeting release v2.16.0 labels Jul 26, 2024
@dbwiddis
Copy link
Member Author

dbwiddis commented Aug 7, 2024

This can be addressed as part of #823

@dbwiddis dbwiddis added v2.18.0 Issues targeting release v2.18.0 and removed backlog Good to have functionality not critical for next release labels Sep 18, 2024
@dbwiddis dbwiddis added v2.19.0 and removed v2.18.0 Issues targeting release v2.18.0 labels Oct 11, 2024
@minalsha minalsha assigned saimedhi and unassigned amitgalitz Oct 11, 2024
@minalsha minalsha assigned junweid62 and unassigned saimedhi Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working v2.19.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants