<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 2: Code-Review-1</p><p style="white-space: pre-wrap; word-wrap: break-word;">(5 comments)</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 2:</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 2: Code-Review-1</p><p style="white-space: pre-wrap; word-wrap: break-word;">(3 comments)</p><p style="white-space: pre-wrap; word-wrap: break-word;">The concern that comes to mind is the test becoming fragile in the future if we use taskprocessors in other ways, thus having to continue to update and tweak the test condition. Thoughts Richard and Kevin?</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Anything that processes Asterisk CLI output is going to be fragile.  The CLI output is not intended to be stable.  It is targeted for human consumption.  The output of "core show taskprocessors" has changed several times as new things are tracked.  The task processor names have changed a few times too.  The "outsess" task processor name series has changed from its original naming as internal organization changed.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">I agree it is somewhat fragile, but I think most, if not all the test conditions scrape the CLI. Also as long as the screen column order doesn't change (which I don't think it has in a while if at all) then that fragility is lessened except ....for the hard-coded named "outsess".</p><p style="white-space: pre-wrap; word-wrap: break-word;">Not really sure of a good way around this. It can be moved to a configurable list, but then that'd potentially have to change.</p><p style="white-space: pre-wrap; word-wrap: break-word;">I'm fine allowing this for now though. Hopefully taskprocessors, and their names are fairly stabilized for now. If it becomes a problem we can reassess later.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">FWIW, I borrowed most of this code from the existing filedescriptor test condition, which operates in the same way, with a "core show fd". I agree that parsing CLI output is not ideal, but I couldn't find any other interface that exposes this problem, and think this is definitely better than nothing.</p><p><a href="https://gerrit.asterisk.org/c/testsuite/+/14210">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.asterisk.org/c/testsuite/+/14210">change 14210</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/c/testsuite/+/14210"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: testsuite </div>
<div style="display:none"> Gerrit-Branch: 16 </div>
<div style="display:none"> Gerrit-Change-Id: I90451cca574e2fa7d825b4cdc0bab03e331c0e9b </div>
<div style="display:none"> Gerrit-Change-Number: 14210 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: lvl <digium@lvlconsultancy.nl> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@sangoma.com> </div>
<div style="display:none"> Gerrit-Reviewer: Kevin Harwell <kharwell@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 30 Apr 2020 09:42:58 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>