Ethsim2
11 أكتوبر 2026، 9:57ص
2
مرحباً @scavin ، شكراً لك على الإبلاغ عن هذه المشكلة وتوفير تفاصيل إعادة إنتاجها.
لقد كنت أبحث في بطء نقطة النهاية الخاصة بـ Markdown التي وصفتها، وحديت مشكلة في MarkdownEndpoint::CookedProcessor#replace_details: حيث كانت عناصر <details> المتداخلة تُحوَّل بشكل متكرر، مما أدى إلى معالجة أُسّية (exponential processing).
لقد فتحت طلب سحب (PR) مسودة (draft) على المنبع (upstream) يحتوي على الإصلاح:
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.
- The original performance-fix commit passed upstream CI.
- The updated two-commit PR requires a fresh CI run.
## 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)
عند مستوى تدخّل ثامن، قلّل الإصلاح عمليات التحويل التكرارية من 255 إلى 8، مع تحقيق تسريع يقارب 31 ضعفًا في اختباري المحلي للأداء. وقد اجتاز طلب السحب فحوصات GitHub CI الأولية.
أعمل أيضًا على إعداد الموقع المقترح من قِبلك details_max_nesting_depth داخل إضافة Details المدمجة، باستخدام 0 لـ عدم تحديد حد للتدخّل للحفاظ على السلوك الحالي. تم كتابة التنفيذ الأولي، لكن اختبارات التكامل لا تزال قيد الإنجاز.
يعالج إصلاح الأداء مشكلة تحويل Markdown على جانب الخادم؛ بينما سيوفر الحد القابل للتخصيص حماية إضافية، خاصةً لأداء جانب المتصفح.
أرحب بالملاحظات حول الإعداد المقترح، وما إذا كان من الأفضل تضمينه في نفس طلب السحب أو إرساله بشكل منفصل.
إعجاب واحد (1)