BEP emits same startTime and endTime for actions

[jpopadak]

Description of the bug:

ActionExecutedEvent is constructed with its end_time accidentally set to firstStartTime (copy-paste error), causing start_time == end_time in BEP ActionExecuted/ActionCompleted events. This caused an action duration of zero on all events if you took end_time - start_time.

bazel/src/main/java/com/google/devtools/build/lib/skyframe/SkyframeActionExecutor.java

Lines 1936 to 1937 in feeab92

	firstStartTime.equals(Instant.MAX) ? null : firstStartTime,
	lastEndTime.equals(Instant.MIN) ? null : firstStartTime));

The lastEndTime should be used (preserving the existing null/Instant.MIN checks) so the recorded end time reflects the actual last spawn end time.

Which category does this issue belong to?

Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Clone bazel locally
2. Run bazel build --build_event_json_file=bes.json --build_event_publish_all_actions //src/test/java/com/google/devtools/build/lib/skyframe:testutil

Result - Note the startTime and endTime are the same for all actionCompleted events:

{
  "id":
    {
      "actionCompleted":
        {
          "primaryOutput": "bazel-out/darwin_arm64-fastbuild/bin/external/rules_jvm_external++maven+maven/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar",
          "label": "@@rules_jvm_external++maven+maven//:com_google_guava_failureaccess_1_0_3_extension",
          "configuration":
            {
              "id": "d1f6811331d3a440c0da9298e18171a8ccf5fe5ab9a613b428ff1fc8bc0de897",
            },
        },
    },
  "action":
    {
      "success": true,
      "label": "@@rules_jvm_external++maven+maven//:com_google_guava_failureaccess_1_0_3_extension",
      "primaryOutput":
        {
          "uri": "file:///Volumes/CSData/bazel/userroot/3da90fca3ee963bc723c807859705665/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_jvm_external++maven+maven/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar",
        },
      "configuration":
        {
          "id": "d1f6811331d3a440c0da9298e18171a8ccf5fe5ab9a613b428ff1fc8bc0de897",
        },
      "type": "Genrule",
      "commandLine":
        [
          "/bin/bash",
          "-c",
          "source external/bazel_tools/tools/genrule/genrule-setup.sh; cp external/rules_jvm_external++maven+com_google_guava_failureaccess_1_0_3/file/v1/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar bazel-out/darwin_arm64-fastbuild/bin/external/rules_jvm_external++maven+maven/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar",
        ],
      "startTime": "2026-01-20T21:13:52.170852Z",
      "endTime": "2026-01-20T21:13:52.170852Z",
    },
}

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 8.4.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

git@github.com:bazelbuild/bazel.git
19d637906594a9f49777f27384c73c8bdab83419

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

877f845

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

@michaeledgar

[brentleyjones]

@fmeum Is this cherry-pickable into 8.6/9.1?

[fmeum]

@bazel-io fork 9.0.1

[fmeum]

@bazel-io fork 8.6.0