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

check connection worker on temporal #2312

Merged
merged 3 commits into from
Mar 5, 2021

Conversation

cgardens
Copy link
Contributor

@cgardens cgardens commented Mar 4, 2021

What

  • Move check connection run in temporal

Pre-merge Checklist

  • Test!

Recommended reading order

  1. test.java
  2. component.ts
  3. the rest

Approach

@jrhizor how do you feel about this approach to migration. it leaves the workers intact, which I think makes refactoring after the fact a little easier. It also gives us more ability to do whatever generic temporal base class we might want to do to abstract away like setting up log paths, MDCs, etc (for now we are just duplicating that logic). It also means we don't need to re do a lot of tests since the Workers are already well tested.

the one annoying downside is that Workers output OutputAndStatus which is not serializable, so we need to unwrap it and then rewrap it (see CheckConnectionWorkflow and TemporalClient). This is annoying, but once all workers are on temporal we can just remove OutputAndStatus from the worker iface. wdyt?

(update, jared and I discussed offline and agreed that this is okay as an intermediate step.)

if (run.getStatus() == JobStatus.SUCCEEDED) {
Preconditions.checkState(run.getOutput().isPresent());
LOGGER.info("job output {}", run.getOutput().get());
return run.getOutput().get();
Copy link
Contributor Author

@cgardens cgardens Mar 4, 2021

Choose a reason for hiding this comment

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

unwrap 🤷‍♀️

.withJobId(jobId)
.withAttemptId((long) attempt)
.withDockerImage(config.getDockerImage());
try {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

rewrap 🤦‍♀️

@cgardens cgardens requested a review from jrhizor March 5, 2021 00:35
@cgardens cgardens marked this pull request as ready for review March 5, 2021 00:42
@cgardens cgardens merged commit a9dc8e8 into master Mar 5, 2021
@cgardens cgardens deleted the cgardens/check_connection_worker_on_temporal branch March 5, 2021 02:30
Copy link
Contributor

@michel-tricot michel-tricot left a comment

Choose a reason for hiding this comment

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

I like the shape it is taking!

LOGGER.info("job output {}", run.getOutput().get());
return run.getOutput().get();
} else {
throw new TemporalJobException();
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is going to work. You're catching and re-throwing as a runtime

.resolve(String.valueOf(launcherConfig.getJobId()))
.resolve(String.valueOf(launcherConfig.getAttemptId().intValue()));

MDC.put("job_id", String.valueOf(launcherConfig.getJobId()));
Copy link
Contributor

Choose a reason for hiding this comment

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

Are you planning to DRY the MDC config?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah. jared just did it in his PR. i'm hoping we can do a base class of some sort so that we don't need to have to remember to do these over and over again.

} else {
throw new RuntimeException(String.format("Spec job subprocess finished with exit code %s", exitCode));
throw new TemporalJobException();
Copy link
Contributor

Choose a reason for hiding this comment

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

Same

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add some tests for these classes? That would likely have caught this bug

try {
return new OutputAndStatus<>(JobStatus.SUCCEEDED, supplier.get());
} catch (TemporalJobException e) {
return new OutputAndStatus<>(JobStatus.FAILED);
Copy link
Contributor

Choose a reason for hiding this comment

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

This will never happen based on the worker code

private OutputAndStatus<JobOutput> toOutputAndStatus(CheckedSupplier<JobOutput, TemporalJobException> supplier) {
try {
return new OutputAndStatus<>(JobStatus.SUCCEEDED, supplier.get());
} catch (TemporalJobException e) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since you're also throwing runtime, what do you expect the behavior for the output ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup. the exception handling is not good right now. i will be looking at it across the board today and fix these.

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