[nikosbosse]

CLAUDE: Closes #1236.

What

transform_forecasts() updated the forecast object with :=, and [.forecast re-validates the whole object after every such update. One call therefore ran assert_forecast() six times with append = TRUE and three times with append = FALSE. Multivariate forecasts paid for one more validation on top, because the method rebuilt an object that had just been built.

The transformation now lives in an internal helper, transform_forecast_data(). It validates the input once (clean_forecast()) and does all := updates and the rbind() on a plain data.table. Each method then builds the forecast object once with the matching as_forecast_<type>(). That makes two validations per call for every forecast type and both values of append. With append = FALSE, multivariate forecasts keep their existing .mv_group_id, since the rows and groups don't change.

The smaller items in the issue (check_observed_constant(), check_number_per_forecast(), get_duplicate_forecasts()) are left for a separate PR.

Timing

On the reprex in #1236 (120k quantile forecasts, 2.76M rows):

	main	this PR
append = TRUE	19.9 s	9.5 s
append = FALSE	7.3 s	5.0 s

The remaining time is mostly the two validations; the output of append = TRUE has twice as many rows as the input. Skipping input validation would save about another 2 s, but then invalid input would fail inside fun() with an obscure error.

Behaviour change

With append = FALSE, a transformation that produced an invalid forecast used to return it, with "Error in validating forecast object" warnings. It now errors, as it already did with append = TRUE. For example, fun = as.character now errors, and so does a fun that returns all NA. This is in NEWS.

The most likely way to hit this is calling append = FALSE on an already-transformed forecast with a label that is already in scale. That includes the default "log" after a default transformation. That call duplicates forecasts, so it now gets its own clear error ("Can't transform with label 'log' ...") instead of a duplicate-forecast error. The label docs now say this.

Checks

• For quantile, sample, point and multivariate sample forecasts, outputs are identical to main's for append = TRUE, append = FALSE, and append = FALSE on an already-transformed object with a new label.
• New tests cover:
  • the validation count for quantile and multivariate forecasts (they fail on main, with 6 and 3 for quantile);
  • that the input is not modified, with and without an existing scale column;
  • the errors on invalid output and on a reused label;
  • multivariate grouping with append = FALSE.
• An independent review found no correctness bugs. Its findings (reused label, multivariate grouping, a redundant copy, test breadth) are addressed in the second commit.
• devtools::test() passes. lintr reports no lints on the changed files. Coverage of R/transform-forecasts.R stays at 100%.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.18%. Comparing base (8b18f07) to head (24d5b02).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1238      +/-   ##
==========================================
- Coverage   99.18%   99.18%   -0.01%     
==========================================
  Files          41       41              
  Lines        2333     2331       -2     
==========================================
- Hits         2314     2312       -2     
  Misses         19       19              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[nikosbosse]

@seabbs looks good to me