Subject: TAP output format in pg_regress

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 22 Feb 2022 00:08:11 +0100

Starting a new thread on the TAP patch from the "[RFC] building postgres with
meson" thread at [email-masked] to have
somewhere to discuss this patch.

> On 21 Feb 2022, at 17:52, Andres Freund <[email-masked]> wrote:
> On 2021-10-13 13:54:10 +0200, Daniel Gustafsson wrote:

>> I added a --tap option for TAP output to pg_regress together with Jinbao Chen
>> for giggles and killing some time a while back.
> 
> Sorry for not replying to this earlier. I somehow thought I had, but the
> archives disagree.

No worries, I had forgotten about it myself.

> I think this would be great.

Cool, I'll pick it up again then.  I didn't have time to dig into the patch
tonight but the attached is a rebased version which just cleans up the bitrot
it had accumulated to the point where it at least compiles and seems to run.

>> One thing that came out of this, is that we don't really handle the ignored
>> tests in the way the code thinks it does for normal output, the attached treats
>> ignored tests as SKIP tests.
> 
> I can't really parse the first sentence...

I admittedly don't remember exactly what I meant, but I'm fairly sure it's
wrong.  I think I thought ignored tests were counted incorrectly, but skimming
the patch just now I think it's doing it wrong as it counts ignored as failed
even if they passed.  I'll fix that.

>> 	if (exit_status != 0)
>> 		log_child_failure(exit_status);
>> @@ -2152,6 +2413,7 @@ regression_main(int argc, char *argv[],
>> 		{"config-auth", required_argument, NULL, 24},
>> 		{"max-concurrent-tests", required_argument, NULL, 25},
>> 		{"make-testtablespace-dir", no_argument, NULL, 26},
>> +		{"tap", no_argument, NULL, 27},
>> 		{NULL, 0, NULL, 0}
>> 	};
> 
> I'd make it a --format=(regress|tap) or such.

That makes sense, done in the attached.

--
Daniel Gustafsson		https://vmware.com/

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 22 Feb 2022 15:10:11 +0100

> On 22 Feb 2022, at 00:08, Daniel Gustafsson <[email-masked]> wrote:

> I'll fix that.

The attached v3 fixes that thinko, and cleans up a lot of the output which
isn't diagnostic per the TAP spec to make it less noisy.  It also fixes tag
support used in the ECPG tests and a few small cleanups.  There is a blank line
printed which needs to be fixed, but I'm running out of time and wanted to get
a non-broken version on the list before putting it aside for today.

The errorpaths that exit(2) the testrun should be converted to "bail out" lines
when running with TAP output, but apart from that I think it's fairly spec
compliant.

---

From: Andres Freund <[email-masked]>
Date: Tue, 22 Feb 2022 09:13:31 -0800

Hi,

Thanks for the updated version!

> when running with TAP output, but apart from that I think it's fairly spec

I'd much rather not use BAIL - I haven't gotten around to doing anything about
it, but I really want to get rid of nearly all our uses of bail:

https://www.postgresql.org/message-id/20220213232249.7sevhlioapydla37%40alap3.anarazel.de

Greetings,

Andres Freund

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 22 Feb 2022 22:04:38 +0100

> On 22 Feb 2022, at 18:13, Andres Freund <[email-masked]> wrote:

> it, but I really want to get rid of nearly all our uses of bail:

Point.  We already error out on stderr in pg_regress so we could probably make
die() equivalent output to keep the TAP parsing consistent.  At any rate,
awaiting the conclusions on the bail thread and simply (for some value of)
replicating that in this patch is probably the best option?

---

From: Andres Freund <[email-masked]>
Date: Mon, 21 Mar 2022 16:49:24 -0700

Hi,

> when running with TAP output, but apart from that I think it's fairly spec

This is failing with segmentation faults on cfbot:
https://cirrus-ci.com/task/4879227009892352?logs=test_world#L21

Looks like something around isolationtester is broken?

Unfortunately there's no useful backtraces for isolationtester. Not sure
what's up there.

Seems like we might not have energy to push this forward in the next two
weeks, so maybe the CF entry should be marked returned or moved for now?

Greetings,

Andres Freund

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 24 Mar 2022 13:44:51 +0100

> On 22 Mar 2022, at 00:49, Andres Freund <[email-masked]> wrote:

> Looks like something around isolationtester is broken?

It could be triggered by plpgsql tests as well, and was (as usual) a silly
mistake easily fixed when found.  The attached survices repeated check-world
for me.

> weeks, so maybe the CF entry should be marked returned or moved for now?

Since there is little use for this without the Meson branch, it should target
the same version as that patch. I'll move the patch to the next CF for now.

As we discussed off-list I extended this patchset with an attempt to minimize
noise as per [email-masked], but it's not
yet done.  The attached has a rough draft of adding a --verbose option which
gives the current output (and potentially more for debugging), but which by
default is off producing minimal noise.

---

From: Daniel Gustafsson <[email-masked]>
Date: Wed, 29 Jun 2022 21:50:45 +0200

Attached is a new version of this patch, which completes the TAP output format
option such that all codepaths emitting output are TAP compliant.  The verbose
option is fixed to to not output extraneous newlines which the previous PoC
did.  The output it made to conform to the original TAP spec since v13/14 TAP
parsers seem less common than those that can handle the original spec.  Support
for the new format additions should be quite simple to add should we want that.

Running pg_regress --verbose should give the current format output.

I did end up combining TAP and --verbose into a single patch, as the TAP format
sort of depends on the verbose flag as TAP has no verbose mode.  I can split it
into two separate should a reviewer prefer that.

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 4 Jul 2022 16:27:20 +0200

> into two separate should a reviewer prefer that.

I'm not sure what to make of all these options.  I think providing a TAP 
output for pg_regress is a good idea.  But then do we still need the old 
output?  Is it worth maintaining two output formats that display exactly 
the same thing in slightly different ways?

What is the purpose of the --verbose option?  When and how is one 
supposed to activate that?  The proposed default format now hides the 
fact that some tests are started in parallel.  I remember the last time 
I wanted to tweak the output of the parallel tests, people were very 
attached to the particular timing and spacing of the current output.  So 
I'm not sure people will like this.

The timing output is very popular.  Where is that in the TAP output?

More generally, what do you envision we do with this feature?  Who is it 
for, what are the tradeoffs, etc.?

---

From: Tom Lane <[email-masked]>
Date: Mon, 04 Jul 2022 10:39:37 -0400

Probably is, because this is bad:

> ... The proposed default format now hides the 

> The timing output is very popular.  Where is that in the TAP output?

Both of those things are fairly critical for test development.  You
need to know what else might be running in parallel with a test case,
and you need to know whether you just bloated the runtime unreasonably.

More generally, I'm unhappy about the proposal that TAP should become
the default output.  There is nothing particularly human-friendly
about it, whereas the existing format is something we have tuned to
our liking over literally decades.  I don't mind if there's a way to
get TAP when you're actually intending to feed it into a TAP-parsing
tool, but I am not a TAP-parsing tool and I don't see why I should
have to put up with it.

			regards, tom lane

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 4 Jul 2022 21:33:36 +0200

> and you need to know whether you just bloated the runtime unreasonably.

I don't think there is a reason these couldn't be shown in TAP output as 
well.

Even if we keep the two output formats in parallel, it would be good if 
they showed the same set of information.

---

From: Andres Freund <[email-masked]>
Date: Mon, 4 Jul 2022 13:06:17 -0700

Hi,

> and you need to know whether you just bloated the runtime unreasonably.

That should be doable with tap as well - afaics the output of that could
nearly be the same as now, preceded by a #.

The test timing output could (and I think should) also be output - but if I
read the tap specification correctly, we'd either need to make it part of the
test "description" or on a separate line.

> tool, but I am not a TAP-parsing tool and I don't see why I should

I'm mostly interested in the tap format because meson's testrunner can parse
it - unsurprisingly it doesn't understand the current regress output. It's a
lot nicer to immediately be pointed to the failed test(s) than having to scan
through the output "manually".

Greetings,

Andres Freund

---

From: Andres Freund <[email-masked]>
Date: Mon, 4 Jul 2022 13:13:52 -0700

Hi,

On 2022-06-29 21:50:45 +0200, Daniel Gustafsson wrote:
> @@ -279,8 +648,7 @@ stop_postmaster(void)
>  		r = system(buf);
>  		if (r != 0)
>  		{
> -			fprintf(stderr, _("\n%s: could not stop postmaster: exit code was %d\n"),
> -					progname, r);
> +			pg_log_error("could not stop postmaster: exit code was %d", r);
>  			_exit(2);			/* not exit(), that could be recursive */
>  		}

There's a lot of stuff like this. Perhaps worth doing separately? I'm not sure
I unerstand where you used bail and where not. I assume it's mostly arund use
uf _exit() vs exit()?

> +				test_status_ok(tests[i]);
>  
>  			if (statuses[i] != 0)
>  				log_child_failure(statuses[i]);
>  
>  			INSTR_TIME_SUBTRACT(stoptimes[i], starttimes[i]);
> -			status(_(" %8.0f ms"), INSTR_TIME_GET_MILLISEC(stoptimes[i]));
> +			runtime(tests[i], INSTR_TIME_GET_MILLISEC(stoptimes[i]));

Based on the discussion downthread, let's just always compute this and display
it even in the tap format?

Greetings,

Andres Freund

---

From: Daniel Gustafsson <[email-masked]>
Date: Mon, 4 Jul 2022 23:48:02 +0200

> On 4 Jul 2022, at 22:13, Andres Freund <[email-masked]> wrote:
> 
> Hi,
> 

Since bail will cause the entire testrun to be considered a failure, the idea
was to avoid using bail() for any errors in tearing down the test harness after
an otherwise successful test run.

Moving to pg_log_error() can for sure be broken out into a separate patch from
the rest of the set (if we at all want to do that, but it seemed logical to
address when dealing with other output routines).

> it even in the tap format?

Sure, it's easy enough to do and include in the test description.  The reason I
left it out is that the test runners I played around with all hide those
details and only show a running total.  That of course doesn't mean that all
runners will do that (and anyone running TAP output for human consumption will
want it), so I agree with putting it in, I'll fix that up in a v6 shortly.

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 5 Jul 2022 00:06:04 +0200

> On 4 Jul 2022, at 16:27, Peter Eisentraut <[email-masked]> wrote:
> 
> I'm not sure what to make of all these options.  I think providing a TAP output for pg_regress is a good idea.  But then do we still need the old output?  Is it worth maintaining two output formats that display exactly the same thing in slightly different ways?

If we believe that TAP is good enough for human consumption and not just as
input to test runners then we don't.  Personally I think the traditional format
is more pleasant to read than raw TAP output when running tests.

> What is the purpose of the --verbose option?  When and how is one supposed to activate that?  The proposed default format now hides the fact that some tests are started in parallel.

The discussion on this was in [email-masked]
where it was proposed that we could cut the boilerplate.  Thinking on it I
agree that the parallel run info should be included even without --verbose so
I'll add that back.  In general, running with --verbose should ideally only be
required for troubleshooting setup/teardown issues with testing.

>  I remember the last time I wanted to tweak the output of the parallel tests, people were very attached to the particular timing and spacing of the current output.  So I'm not sure people will like this.
> 

As I mentioned in the mail upthread, TAP runners generally hide that info and
only show a running total.  That being said, I do agree with adding back so
I'll do that in a new version of the patch.

> More generally, what do you envision we do with this feature?  Who is it for, what are the tradeoffs, etc.?

In general, my thinking with this was that normal testruns started with make
check (or similar) by developers would use the traditional format (albeit less
verbose) and that the TAP output was for automated test runners in general and
the meson test runner in particular.  The TAP format is an opt-in with the
traditional format being the default.

The tradeoff is of course that maintaining two output formats is more work than
maintaining one, but it's not really something we change all that often so that
might not be too heavy a burden.

I personally didn't see us replacing the traditional format for "human
readable" runs, if that's where the discussion is heading then the patch can
look quite different.  Having test output format parity with supported back
branches seemed like a good idea to me at the time of writing at least.

---

From: Tom Lane <[email-masked]>
Date: Mon, 04 Jul 2022 18:06:31 -0400

> nearly be the same as now, preceded by a #.

I don't mind minor changes like prefixing # --- I just don't want
to lose information.

			regards, tom lane

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 5 Jul 2022 00:11:13 +0200

> On 4 Jul 2022, at 16:39, Tom Lane <[email-masked]> wrote:
> 
> the default output.  

That's not my proposal though, my proposal is that the traditional format
should be the default output (with the parallel test info added back, that was
my bad), and that TAP is used in automated test runners like in meson.  Hiding
the timing in TAP was (as mentioned upthread) since TAP test runners generally
never show that anyways, but I'll add it back since it clearly doesn't hurt to
have even there.

> There is nothing particularly human-friendly

I totally agree, and that's why the patch has the traditional format - without
all the boilerplate - as the default.  Unless opting-in there is no change over
today, apart from the boilerplate.

---

From: Andres Freund <[email-masked]>
Date: Mon, 4 Jul 2022 15:58:31 -0700

Hi,

> is more pleasant to read than raw TAP output when running tests.

I think with a bit of care the tap output could be nearly the same
"quality". It might not be the absolute "purest" tap output, but who cares.

test tablespace                   ... ok          418 ms
parallel group (20 tests):  oid char int2 varchar name int4 text pg_lsn regproc txid money boolean uuid float4 int8 float8 bit enum rangetypes numeric
     boolean                      ... ok           34 ms
     char                         ... ok           20 ms
     name                         ... ok           26 ms

isn't that different from

ok 1 - tablespace           418ms
# parallel group (20 tests):  oid char int2 varchar name int4 text pg_lsn regproc txid money boolean uuid float4 int8 float8 bit enum rangetypes numeric
ok 2 -      boolean        34ms
ok 3 -      char           20ms
ok 4 -      name           26ms

or whatever.

For non-parallel tests I think we currently print the test name before running
the test, which obviously doesn't work well when needing to print the 'ok'
'not ok' first. We could just print
# non-parallel group tablespace
or such? That doesn't

I wonder if for parallel tests we should print the test number based on the
start of the test rather than the finish time? Hm, it also looks like it's
legal to just leave the test number out?

> where it was proposed that we could cut the boilerplate.

I think that was more about things like CREATE DATABASE etc. And I'm not sure
we need an option to keep showing those details.

> I'll do that in a new version of the patch.

FWIW, meson's testrunner shows the individual tap output when using -v.

One test where using -v is a problem is pg_dump's tests - the absurd number of
8169 tests makes showing that decidedly not fun.

> Having test output format parity with supported back branches seemed like a
> good idea to me at the time of writing at least.

That's of course nice, but it also kind of corners us into not evolving the
default format, which I don't think is warranted...

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Mon, 04 Jul 2022 21:56:24 -0400

> "quality". It might not be the absolute "purest" tap output, but who cares.

+1

> 'not ok' first.

Is this still a consideration?  We got rid of serial_schedule some
time ago.

> start of the test rather than the finish time?

I think we need the test number to be stable, so it had better be the
ordering appearing in the schedule file.  But we already print the
results in that order.

			regards, tom lane

---

From: Andres Freund <[email-masked]>
Date: Mon, 4 Jul 2022 19:40:11 -0700

Hi,

> Is this still a consideration?  We got rid of serial_schedule some

Not really for the main tests, there's a few serial steps, but not enough that
a bit additional output would be an issue. I think all tests in contrib are
serial though, and some have enough tests that it might be annoying?

> ordering appearing in the schedule file.  But we already print the

I remembered some asynchronizity, but apparently that's just the "parallel
group" line.

Greetings,

Andres Freund

---

From: Jacob Champion <[email-masked]>
Date: Tue, 2 Aug 2022 11:44:30 -0700

This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.

Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting

    https://commitfest.postgresql.org/38/3559/

and changing the status to "Needs Review", and then changing the
status again to "Move to next CF". (Don't forget the second step;
hopefully we will have streamlined this in the near future!)

Thanks,
--Jacob

---

From: Daniel Gustafsson <[email-masked]>
Date: Wed, 17 Aug 2022 23:04:20 +0200

Attached is a new version of the pg_regress TAP patch which - per reviewer
feedback - does away with dual output formats and just converts the existing
output to be TAP complaint.  The idea was to keep it fairly human readable
while still be TAP compliant enough that running it with prove (with a tiny
Perl wrapper) works.  This version also strips away the verbose output which
these days isn't terribly useful and mainly consume vertical space.  Another
feature of the patch is to switch error logging to using the common frontend
logging rather than pg_regress rolling its own.  The output from pg_log_error
is emitted verbatim by prove as it's on stderr.

I based the support on the original TAP specification and not the new v13 or
v14 since it seemed unclear how well those are supported in testrunners.  If
v14 is adopted by testrunners there are some better functionality for reporting
errors that we could use, but for how this version seems a safer option.

A normal "make check" with this patch applied now looks like this:

+++ regress check in src/test/regress +++
# running on port 61696 with PID 57910
ok 1 - test_setup                       326 ms
ok 2 - tablespace                       401 ms
# parallel group (20 tests):  varchar char oid pg_lsn txid int4 regproc money int2 uuid float4 text name boolean int8 enum float8 bit numeric rangetypes
ok 3 - boolean                          129 ms
ok 4 - char                              73 ms
ok 5 - name                             117 ms
ok 6 - varchar                           68 ms
<...snip...>
ok 210 - memoize                        137 ms
ok 211 - stats                          851 ms
# parallel group (2 tests):  event_trigger oidjoins
ok 212 - event_trigger                  138 ms
not ok 213 - oidjoins                   190 ms
ok 214 - fast_default                   149 ms
1..214
# 1 of 214 tests failed.
# The differences that caused some tests to fail can be viewed in the
# file "/<path>/src/test/regress/regression.diffs".  A copy of the test summary that you see
# above is saved in the file "/<path>/src/test/regress/regression.out".

The ending comment isn't currently shown when executed via prove as it has to
go to STDERR for that to work, and I'm not sure that's something we want to do
in the general case.  I don't expect running the pg_regress tests via prove is
going to be the common case.  How does the meson TAP ingestion handle
stdout/stderr?

And for the sake of completeness, even though we all know this by heart, a
similar run from the current output format looks like:

+++ regress check in src/test/regress +++
============== creating temporary instance            ==============
============== initializing database system           ==============
============== starting postmaster                    ==============
running on port 61696 with PID 61955
============== creating database "regression"         ==============
CREATE DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
============== running regression test queries        ==============
test test_setup                   ... ok          469 ms
test tablespace                   ... ok          415 ms
parallel group (20 tests):  varchar char oid name int2 pg_lsn int4 txid text uuid regproc boolean money float4 int8 float8 bit enum numeric rangetypes
     boolean                      ... ok          105 ms
     char                         ... ok           64 ms
     name                         ... ok           70 ms
     varchar                      ... ok           55 ms
<...snip...>
     memoize                      ... ok          149 ms
     stats                        ... ok          873 ms
parallel group (2 tests):  event_trigger oidjoins
     event_trigger                ... FAILED      142 ms
     oidjoins                     ... FAILED      208 ms
test fast_default                 ... ok          172 ms
============== shutting down postmaster               ==============

========================
 2 of 214 tests failed.
========================

The differences that caused some tests to fail can be viewed in the
file "/<path>/src/test/regress/regression.diffs".  A copy of the test summary that you see
above is saved in the file "/<path>/src/test/regress/regression.out".

There is a slight reduction in information, for example around tests run
serially vs in a parallel group.  This could perhaps be handled by marking the
test name in some way like "tablespace (serial) or prefixing with a symbol or
somerthing.  I can take a stab at that in case we think that level of detail is
important to preserve.

---

From: Andres Freund <[email-masked]>
Date: Wed, 17 Aug 2022 15:49:49 -0700

Hi,

On 2022-08-17 23:04:20 +0200, Daniel Gustafsson wrote:
> output to be TAP complaint.

Cool.

> Perl wrapper) works.

Wonder if we could utilize that for making failures of 002_pg_upgrade.pl and
027_stream_regress.pl easier to understand, by reporting pg_regress' steps as
part of the outer test. But that'd probably be at least somewhat hard, due to
the embedded test count etc.

> This version also strips away the verbose output which these days isn't
> terribly useful and mainly consume vertical space.

Yay.

> Another feature of the patch is to switch error logging to using the common
> frontend logging rather than pg_regress rolling its own.  The output from
> pg_log_error is emitted verbatim by prove as it's on stderr.

Sounds good.

> errors that we could use, but for how this version seems a safer option.

Yep, that makes sense.

> # above is saved in the file "/<path>/src/test/regress/regression.out".

I'm happy with that compared to our current output.

> going to be the common case.  How does the meson TAP ingestion handle

It'll parse stdout for tap output and log stderr output separately.

> somerthing.  I can take a stab at that in case we think that level of detail is

I think we could just indent the test "description" for tests in parallel
groups:

I.e. instead of

ok 1 - test_setup                       326 ms
ok 2 - tablespace                       401 ms

do

ok 1 - test_setup                       326 ms
ok 2 - tablespace                       401 ms

that'd make it sufficiently clear, and is a bit more similar to the current
format?

I wonder if we should indent the test name so that the number doesn't cause
wrapping? And perhaps we can skip the - in that case?

I.e. instead of:

ok 9 - name                             117 ms
ok 10 - varchar                          68 ms
..
ok 99 - something                        60 ms
ok 100 - memoize                        137 ms

something like:

ok 9    name                            117 ms
ok 10   varchar                          68 ms
...
ok 99   something                        60 ms
ok 100  memoize                         137 ms

with parallel tests:

ok 9    name                            117 ms
# parallel group (2 tests):  varchar varchar2
ok 10           varchar                  68 ms
ok 11           varchar2                139 ms
ok 12   varchar3                         44 ms
ok 99   something                        60 ms
ok 100  memoize                         137 ms

Greetings,

Andres Freund

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 18 Aug 2022 13:24:20 +0200

> On 18 Aug 2022, at 00:49, Andres Freund <[email-masked]> wrote:

> the embedded test count etc.

I have a feeling it might require some quite bespoke logic to tie it together
(which may not be worth it in the end) but I'll have a look.

> I'm happy with that compared to our current output.

Great!  Once this thread has settled on a format, maybe it should go to a
separate -hackers thread to get more visibility and (hopefully) buy-in for such
a change.

One thing I haven't researched yet is if the Buildfarm or CFBot parses the
current output in any way or just check the exit status of the testrun.

> It'll parse stdout for tap output and log stderr output separately.

Then I think this patch will be compatible with that.

> that'd make it sufficiently clear, and is a bit more similar to the current

Thats a better option, done that way.

> wrapping?

The tricky part there is that we don't know beforehands how many tests will be
run.  We could add a first pass over the schedule, which seems excessive for
this, or align with a fixed max such that 9999 number of tests is the maximum
number of tests which will print neatly aligned.

> And perhaps we can skip the - in that case?

The dash is listed as "Recommended" but not required in the TAP spec (including
up to v14) so we can skip it.

With these changes, the "worst case" output in terms of testnames alignment
would be something like this (assuming at most 9999 tests):

ok 211               stats                          852 ms
# parallel group (2 tests):  event_trigger oidjoins
ok 212               event_trigger                  149 ms
not ok 213           oidjoins                       194 ms
ok 214       fast_default                           178 ms
1..214

I think that's fairly readable, and not that much different from today.

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 18 Aug 2022 10:40:22 -0400

> current output in any way or just check the exit status of the testrun.

Buildfarm: just the status.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 1 Sep 2022 14:21:18 +0200

> On 18 Aug 2022, at 16:40, Andrew Dunstan <[email-masked]> wrote:
> 

Thanks for confirming, the same is true for CFBot AFAICT.

Attached is a v8 which fixes a compiler warning detected by the CFBot.