Ethsim2
10월 11, 2026, 9:57오전
2
Hi @scavin , 보고해 주시고 재현 단계를 공유해 주셔서 감사합니다.
말씀해 주신 Markdown 엔드포인트 지연 문제를 조사하던 중 MarkdownEndpoint::CookedProcessor#replace_details에서 문제를 발견했습니다. 중첩된 <details> 요소가 반복적으로 변환되어 지수적으로 처리 시간이 증가하는 문제가 있었습니다.
수정 사항을 담은 초안 PR을 업스트림에 열었습니다:
main ← Ethsim12:investigate-details-markdown
opened 08:50AM - 11 Oct 26 UTC
## Background
In [scavin's Discourse Meta report](https://meta.discourse.org/… t/add-a-maximum-nesting-depth-for-collapsible-details/414455), a post containing 24 nested `[details]` sections was associated with severe browser slowdowns and Markdown endpoint timeouts.
Investigation identified redundant recursive processing in `MarkdownEndpoint::CookedProcessor#replace_details`.
## Implemented: Markdown endpoint performance fix
The current implementation visits nested `<details>` elements in document order, recursively converting descendants multiple times.
For a chain of `n` nested details elements, recursive conversion calls grow as `2^n - 1`.
Processing the elements innermost-first using `.to_a.reverse_each` reduces this to `n` recursive conversions in the tested case.
### Reproduction
At nesting depth 8:
| | Original | Patched |
|---|---:|---:|
| Recursive conversions | 255 | 8 |
| Conversion time | 322 ms | 10.5 ms |
The measured speedup was approximately 31x.
### Verification
- Confirmed that the original implementation makes 255 recursive conversions at depth 8, versus 8 after the fix.
- Confirmed identical Markdown output in the synthetic nesting benchmarks.
- Added regression coverage for nested and sibling details.
## Implemented: Configurable nesting limit
Added `details_max_nesting_depth` to the built-in `discourse-details` plugin.
- `0` (default): Unlimited nesting, preserving existing behaviour.
- Positive values from `1` to `100`: Maximum permitted nesting depth.
- Server-side validation applies when creating or editing posts.
- Over-limit submissions receive a translated validation error.
- Existing posts with unchanged raw content are not rejected merely because the setting changes.
- Sibling details do not count as additional nesting levels.
- Nested raw HTML `<details>` elements are also checked.
- Details syntax within fenced code blocks is ignored.
Validation occurs when a post is submitted or edited, not continuously during composition.
### Feature verification
Added 12 feature-specific regression tests:
- 10 model-validation tests covering limits, siblings, raw HTML, code fences and post edits.
- 2 HTTP request tests confirming that rejected creations and edits return HTTP 422 with the validation message.
- The rejected edit test also confirms that the original post remains unchanged.
The combined Markdown endpoint and Details plugin backend suite passed locally:
**34 examples, 0 failures**
Syntax Tree, RuboCop and `git diff --check` also passed.
The performance fix and configurable nesting limit are separate commits so either change can be reviewed independently.
The nesting limit is an additional safeguard; it does not itself guarantee that every browser-side performance issue is prevented.
## References
- [Original Discourse Meta report](https://meta.discourse.org/t/add-a-maximum-nesting-depth-for-collapsible-details/414455)
- [Temporary depth-limit plugin](https://github.com/scavin/discourse-details-depth-limit)
8단계 중첩 수준에서, 이 수정으로 재귀 변환 횟수가 255회에서 8회로 줄었고, 제 로컬 벤치마크에서 약 31배의 성능 향상이 확인되었습니다. 해당 PR은 GitHub CI 초기 검사를 통과했습니다.
또한, 제안해 주신 details_max_nesting_depth 사이트 설정을 내장 Details 플러그인에 구현하고 있습니다. 기존 동작을 유지하기 위해 무제한 중첩을 나타내는 값으로 0을 사용했습니다. 초기 구현은 완료되었으나, 통합 테스트는 아직 진행 중입니다.
성능 수정 사항은 서버 측 Markdown 변환 문제를 해결하며, 설정 가능한 제한은 특히 브라우저 측 성능을 위해 추가적인 안전장치 역할을 할 것입니다.
제안된 설정에 대한 피드백과, 해당 설정을 동일한 PR에 포함할지 별도로 제출할지에 대한 의견을 듣고 싶습니다.
1개의 좋아요