Array formulas in the #SPILL! state don't re-spill when space becomes available
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 58/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- backend
Direzione di ricerca
Start with FormulaVertex.ts and Evaluator.recomputeFormulaVertexValue, especially how setNoSpace() and vertex.array.size.isRef affect a later space check. Reproduce the reported cases with structural changes, clearing a blocking cell, and dependency changes; inspect the paired tests for #1774 and add coverage for recovery without re-entering the formula. Done means a previously blocked array spills when a change makes room, while remaining #SPILL! when it still cannot fit.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
An array formula that returns #SPILL! keeps returning it after the cells around it change so that the result would fit. It only recovers when the formula is re-entered, updateConfig is called, or rebuildAndRecalculate() runs.
const hf = HyperFormula.buildFromArray([[null], ['=SEQUENCE(4)']], {licenseKey: 'gpl-v3', maxRows: 4})
// A2: #SPILL! (A2:A5 would pass maxRows)
hf.removeRows(0, [0, 1])
// the formula is now in A1, where A1:A4 fits, but A1 is still #SPILL!
hf.setCellContents({sheet: 0, col: 0, row: 0}, '=SEQUENCE(4)')
// A1:A4 = 1, 2, 3, 4
The same happens when the spill was blocked by a value and the blocking cell is cleared:
const hf = HyperFormula.buildFromArray([['=SEQUENCE(3)'], ['x']], {licenseKey: 'gpl-v3'})
// A1: #SPILL!
hf.setCellContents({sheet: 0, col: 0, row: 1}, null)
// A1 is still #SPILL!
It also stays #SPILL! after:
- redo of the
removeRowsabove removeColumns(maxColumns: 4,=SEQUENCE(1,4)in B1, then remove column A)moveRowsof another row out from above the formula- a dependency change (
=ARRAYFORMULA(SEQUENCE(4)*B2)in A2, then remove row 1 and change B1)
Undoing the write that blocked the spill does recover.
Cause: when isThereSpaceForArray returns false, setNoSpace() (FormulaVertex.ts) replaces the vertex's array with an ErroredArray of size ArraySize.error() (1×1, isRef), so the vertex no longer knows its real size. Evaluator.recomputeFormulaVertexValue then returns setNoSpace() whenever vertex.array.size.isRef is set, without calling isThereSpaceForArray, so the space check never runs again.
Expected: after a structural change, a cell write, or a dependency change, an array formula in the #SPILL! state should check for space again and spill if the result now fits. Excel Online does this in all three cases:
| Setup | Change | Excel Online |
|---|---|---|
=SEQUENCE(3) in A1048575 → #SPILL! (sheet edge) |
delete rows above | spills 1, 2, 3 |
=SEQUENCE(1,3) in XFC1 → #SPILL! (sheet edge) |
delete column B | moves to XFB1, spills 1, 2, 3 across XFB1:XFD1 |
=SEQUENCE(3) in D10, x in D11 → #SPILL! |
clear D11 | spills 1, 2, 3 in D10:D12 |
Scope: the value-blocked case is pre-existing on develop. #1774 adds a second way into this state: a result that would extend past maxRows/maxColumns returns #SPILL!, so any array near the bottom or right edge of the sheet can get stuck. The paired tests for #1774 (hyperformula-tests#57) cover recovery only by editing the formula and by updateConfig. Their undo and dependency-change tests check that the error stays when the array still doesn't fit. None covers a change that makes room without re-entering the formula.
All cases reproduced on fix/HF-135 at ea7542586. Found by @marcin-kordas-hoc during the review of #1774.
- Lingua principale
- TypeScript
- Stelle
- 2.8k
- Fork
- 174
- Merge medio
- 2g 16h
- PR unite (30g)
- 9
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di handsontable/hyperformula
-
[Bug]: SUBSTITUTE expands dollar sequences in replacement textForse già presa @vera-rubin l’ha presa 5 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
handsontable/hyperformula#1808 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
handsontable/hyperformula#1803 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
handsontable/hyperformula#1793 ·
I maintainer di solito rispondono entro 1 giorno
-
Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
handsontable/hyperformula#1745 ·
I maintainer di solito rispondono entro 1 giorno
-
Bug Impact: Low
Difficoltà 1/5 1-3 ore Idoneità per principianti 68/100
handsontable/hyperformula#1641 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di handsontable/hyperformula
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
jessepollak/home#2223 ·
I maintainer di solito rispondono entro 1 giorno
-
grep fixture corpus test follows the corpus's loop symlink under the receipt runner (fails on main)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
code-yeongyu/senpi#3756 ·
I maintainer di solito rispondono entro 1 giorno
-
org:external package:deepagents priority:triage topic:memory topic:middleware type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
langchain-ai/deepagents#7059 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
osmlab/name-suggestion-index#12992 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
hemilabs/ui-monorepo#2506 ·
I maintainer di solito rispondono entro 1 giorno