Make ManifestMergerAction worker compatible #14427

Bencodes · 2021-12-14T23:01:02Z

Calling System#exit kills the worker during the build. Passing the exception up to the worker should be enough for it to end up in the worker or local execution output.

Bencodes · 2021-12-15T07:24:32Z

src/tools/android/java/com/google/devtools/build/android/ManifestMergerAction.java

@@ -231,11 +231,6 @@ public static void main(String[] args) throws Exception {
        // to the expected location of the output.
        Files.copy(manifest, options.manifestOutput, StandardCopyOption.REPLACE_EXISTING);
      }
-    } catch (AndroidManifestProcessor.ManifestProcessingException e) {


The root Exception can catch everything, minus the System.exit.

This was explicitly added to fix #6904. We should not unfix that.

Thoughts on raising this specific logic up into ResourceProcessorBusyBox where we can log the exception and return the proper exit code inside processRequest?

This would also make the error handing more consistent for any of the other actions that interact with manifest files. DensitySpecificManifestProcessor is another example where a ManifestProcessingException could be thrown, and technically anything that uses AndroidManifest.java can surface this exception as well.

Well, this is a bit strange. There are actually two exception classes with this name:
https://github.com/bazelbuild/bazel/blob/09c621e4cf5b968f4c6cdf905ab142d5961f9ddc/src/tools/android/java/com/google/devtools/build/android/ManifestProcessingException.java

bazel/src/tools/android/java/com/google/devtools/build/android/AndroidManifestProcessor.java

Line 60 in 09c621e

public static class ManifestProcessingException extends RuntimeException {

And they're even both used in the same class:

bazel/src/tools/android/java/com/google/devtools/build/android/AndroidManifest.java

Line 85 in 09c621e

throw new ManifestProcessingException(e);

bazel/src/tools/android/java/com/google/devtools/build/android/AndroidManifest.java

Line 145 in 09c621e

throw new AndroidManifestProcessor.ManifestProcessingException(e);

We should converge onto one to make this less confusing....

Looks like the top-level class is also being used to capture two different kinds of exceptions:

bazel/src/tools/android/java/com/google/devtools/build/android/AndroidManifest.java

Lines 84 to 86 in 09c621e

} catch (IOException | XMLStreamException e) {

throw new ManifestProcessingException(e);

}

IOException is one thing, but XMLStreamException might be from badly formed xml...

Either way, if we just throw here, this exception will get caught by the catch (Exception e) in ResourceProcessorBusyBox, and do the same basic logging. So probably don't need to make ResourceProcessorBusyBox aware of lower level exceptions.

Either way, if we just throw here, this exception will get caught by the catch (Exception e) in ResourceProcessorBusyBox, and do the same basic logging. So probably don't need to make ResourceProcessorBusyBox aware of lower level exceptions.

The generic catch (Exception e) { in ResourceProcessorBusyBox will re-throw the exception after logging the error and bubble that up as an exception coming from main, while catch (AndroidManifestProcessor.ManifestProcessingException e) { gracefully handles the exception with an exit code of 1 being returned directly via the work response (Prior to this PR is was being returned as a System#exit with 1). Is this slight behavioral change fine to merge?

Probably isn't a big deal given that this PR wraps all unhandled exceptions with a proper exit code of 1 in order to confirm to WorkRequestHandler.

https://github.com/bazelbuild/bazel/pull/14428/files#diff-6bbb0aaf4cf2d425734021815617e2b6203223abe7dc76ca8030a90e9f043873R213

@larsrc-google is this in a mergable state so that #14428 is unblocked?

Sorry, I'm catching up on this thread right now -- I'll probably add in a comment in the ManifestProcessingException case handler to explain why its handler is almost the same as the generic case, minus the logging statement. I think it should be fine -- either we have essentially two debug log lines of the same error message, or we have a slightly funky-looking try/catch block. Cutting down on noise in the console seems preferable in this case.

meisterT · 2021-12-20T07:36:10Z

cc @larsrc-google

`ManifestProcessingException` was duplicated somehow and can be removed to avoid confusion. More context: #14427 (comment) Closes #14613. PiperOrigin-RevId: 427074145

nkoroste · 2022-05-03T19:15:05Z

Any updates on this?

ted-xie · 2022-05-11T14:47:18Z

@nkoroste We've merged this upstream!

nkoroste · 2022-05-13T00:57:23Z

Can we add it to 5.2 while we're at it? #15210

ted-xie · 2022-05-16T14:16:07Z

@bazel-io flag

ckolli5 · 2022-06-17T15:17:05Z

@bazel-io fork 5.3.0

Adding support for multiplex workers inside of `ResourceProcessorBusyBox` and moving it's worker implementation over to the generic work request handler. These PRs need to land for this to work: - #14424 - #14425 - #14427 For those not on rolling releases, the other required PRs that have already merged are: - #14144 - #14145 - #14146 Closes #14428. PiperOrigin-RevId: 456561596 Change-Id: I098d5a323ac6558ad0f5f8190e29f45a7a37b4d4

Adding support for multiplex workers inside of `ResourceProcessorBusyBox` and moving it's worker implementation over to the generic work request handler. These PRs need to land for this to work: - bazelbuild#14424 - bazelbuild#14425 - bazelbuild#14427 For those not on rolling releases, the other required PRs that have already merged are: - bazelbuild#14144 - bazelbuild#14145 - bazelbuild#14146 Closes bazelbuild#14428. PiperOrigin-RevId: 456561596 Change-Id: I098d5a323ac6558ad0f5f8190e29f45a7a37b4d4

ckolli5 · 2022-06-29T15:50:13Z

Hello @ted-xie, I cherry-picked these changes and raised a PR against release-5.3.0 branch. Presubmit checks are failing in that PR. Could you please cherry picked with appropriate commits and raise a PR against release-5.3.0? Thanks!

Calling `System#exit` kills the worker during the build. Passing the exception up to the worker should be enough for it to end up in the worker or local execution output. Closes bazelbuild#14427. PiperOrigin-RevId: 447808701

* Support uses-permission merging in manifest merger Adding support for conditionally merging `uses-permissions`. #10628 #5411 Closes #13445. RELNOTES: Enable merging permissions during Android manifest merging with the --merge_android_manifest_permissions flag. PiperOrigin-RevId: 439613035 * Make ManifestMergerAction worker compatible Calling `System#exit` kills the worker during the build. Passing the exception up to the worker should be enough for it to end up in the worker or local execution output. Closes #14427. PiperOrigin-RevId: 447808701 * Fix ManifestMergerAction test case on windows `manifest.toString().replaceFirst("^/", "")` silently fails on windows machines causing `removePermissions` to write to the original test file. This pull request creates a new temp file that `removePermissions` can write the modified manifest to. Pulling this change out of another PR so that it's easier to merge. Original PR here https://github.com/bazelbuild/bazel/pull/13445/files#r631575251 Closes #13760. PiperOrigin-RevId: 438643774 Co-authored-by: Ben Lee <ben@ben.cm>

Bencodes requested a review from ahumesky as a code owner December 14, 2021 23:01

Bencodes mentioned this pull request Dec 14, 2021

Support multiplex workers in ResourceProcessorBusyBox #14428

Closed

Bencodes commented Dec 15, 2021

View reviewed changes

Bencodes force-pushed the make-manifestmergeraction-worker-compatible branch from ef047f4 to ab51ff1 Compare January 10, 2022 19:32

Bencodes mentioned this pull request Jan 21, 2022

Remove duplicate ManifestProcessingException #14613

Closed

gregestren added the team-Performance Issues for Performance teams label Feb 3, 2022

gregestren assigned larsrc-google Feb 3, 2022

Bencodes force-pushed the make-manifestmergeraction-worker-compatible branch from 7654a20 to f3f72d5 Compare February 6, 2022 17:34

bazel-io pushed a commit that referenced this pull request Feb 8, 2022

Remove duplicate ManifestProcessingException

6282ffe

`ManifestProcessingException` was duplicated somehow and can be removed to avoid confusion. More context: #14427 (comment) Closes #14613. PiperOrigin-RevId: 427074145

Bencodes force-pushed the make-manifestmergeraction-worker-compatible branch 2 times, most recently from 23102bd to 73d3414 Compare February 15, 2022 05:06

Make ManifestMergerAction worker compatible

ab345c7

Bencodes force-pushed the make-manifestmergeraction-worker-compatible branch from 73d3414 to ab345c7 Compare April 5, 2022 19:46

Bencodes requested a review from ted-xie as a code owner April 5, 2022 19:46

ahumesky added the team-Android Issues for Android team label Apr 15, 2022

ckolli5 added the awaiting-review PR is awaiting review from an assigned reviewer label May 5, 2022

bazel-io closed this in 075c5a3 May 10, 2022

bazel-io added the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label May 16, 2022

bazel-io mentioned this pull request Jun 17, 2022

[5.3.0] Make ManifestMergerAction worker compatible #15691

Closed

bazel-io removed the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Jun 17, 2022

ckolli5 mentioned this pull request Jun 17, 2022

Make ManifestMergerAction worker compatible #15699

Closed

ShreeM01 removed the awaiting-review PR is awaiting review from an assigned reviewer label Sep 15, 2022

meisterT mentioned this pull request Apr 13, 2023

System.exit in ManifestMergerAction killing persistent worker #11285

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make ManifestMergerAction worker compatible #14427

Make ManifestMergerAction worker compatible #14427

Bencodes commented Dec 14, 2021

Bencodes Dec 15, 2021

larsrc-google Jan 10, 2022

Bencodes Jan 10, 2022 •

edited

Loading

larsrc-google Jan 12, 2022

ahumesky Jan 21, 2022

Bencodes Jan 21, 2022

Bencodes Jan 21, 2022

Bencodes Feb 9, 2022

ted-xie May 10, 2022

meisterT commented Dec 20, 2021

nkoroste commented May 3, 2022

ted-xie commented May 11, 2022

nkoroste commented May 13, 2022

ted-xie commented May 16, 2022

ckolli5 commented Jun 17, 2022

ckolli5 commented Jun 29, 2022

	} catch (IOException \| XMLStreamException e) {
	throw new ManifestProcessingException(e);
	}

Make ManifestMergerAction worker compatible #14427

Make ManifestMergerAction worker compatible #14427

Conversation

Bencodes commented Dec 14, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bencodes Jan 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

meisterT commented Dec 20, 2021

nkoroste commented May 3, 2022

ted-xie commented May 11, 2022

nkoroste commented May 13, 2022

ted-xie commented May 16, 2022

ckolli5 commented Jun 17, 2022

ckolli5 commented Jun 29, 2022

Bencodes Jan 10, 2022 •

edited

Loading