chore: overwrite $CDK_ERROR_FILE on every Error

To go with our changes in aws/aws-cdk-cli#1294:

We can no longer scan `stderr` to find the actual terminating error
code. Best we can do then is guess that it is probably the most recently
thrown error. We will therefore replace the file on every new `Error`
creation, leaving the last error to be found there if the subprocess
happens to exit with an error code.

Author: rix0rrr

packages/aws-cdk-lib/core/lib/errors.ts

@@ -264,38 +264,28 @@ export function renderConstructRootPath(construct: IConstruct) {
   return ret.join('\n');
 }
 
-const THROWN_ERRORS = new Set<string>();
-
 /**
- * If the appropriate environment variable is set, write this error code to a list of error codes in the given file.
- *
- * The reason we do this is so that the CLI can scan `stderr` for one of the
- * error codes between markers, and be confident that when it finds something
- * that it's not user content but an actual error we threw.
+ * If the appropriate environment variable is set, write this error code the given file.
  *
- * - Why not just scan `stderr`? Because customers could put customer content
- *   between those markers, and we would capture user content as an error code (we
- *   explicitly don't want to do that!)
+ * The reason we do this is so that the CLI can see the error code that led to the
+ * termination of the CDK application.
  *
- * - Why not take the error code immediately? Because the error could have been
- *   caught; but we only want to capture the error that terminated the program.
+ * This is not a guarantee: this exception could be caught and a different one
+ * thrown in its stead, in which case we would pick up the wrong error code.
+ * We will take that risk, and assume such cases are rare. The CLI only looks
+ * at the error file if the subprocess terminates with an error, and the most
+ * likely culprit in that case is the most recently thrown error regardless.
  *
- * So we're doing a double whammy of writing potential error codes to a file, then
- * make sure that we find that error code in `stderr`.
+ * Why not use `process.onUncaughtException()`? That will work for pure Node
+ * programs, but in a jsii language no exception is uncaught (the kernel
+ * is always the outermost loop) so that event handler would never fire.
  */
 function maybeWriteErrorCode(errorCode: string) {
   const file = process.env.CDK_ERROR_FILE;
   if (!file) {
     return;
   }
 
-  // Only if this error is new
-  const oldSize = THROWN_ERRORS.size;
-  THROWN_ERRORS.add(errorCode);
-  if (THROWN_ERRORS.size === oldSize) {
-    return;
-  }
-
   // Update the indicated file
-  fs.writeFileSync(file, Array.from(THROWN_ERRORS).sort().join('\n'), 'utf-8');
+  fs.writeFileSync(file, errorCode, 'utf-8');
 }

packages/aws-cdk-lib/core/test/errors.test.ts

@@ -87,7 +87,7 @@ Relates to construct:
     }
   });
 
-  test('writing error codes to disk', async () => {
+  test('most recent error codes is written to disk', async () => {
     const file = path.join(os.tmpdir(), 'errors.txt');
     await rm(file, { force: true });
     try {
@@ -103,7 +103,7 @@ Relates to construct:
         throw new UnscopedValidationError('Error2', 'bla');
       } catch { }
       const contents2 = await readFile(file, 'utf-8');
-      expect(contents2).toEqual('Error1\nError2');
+      expect(contents2).toEqual('Error2');
     } finally {
       delete process.env.CDK_ERROR_FILE;
       await rm(file, { force: true });