Re: Disabling Jenkins Jobs

[Yi Hu via dev]

Hi all,

We have shut down most tests in the Jenkins Load Tests and Performance
Tests categories [1, 2], as they have been migrated to GitHub Actions for a
while and are continuously publishing the metrics as expected. Please refer
to https://github.com/apache/beam/pull/29092 for these tests. Note that
pull requests mostly do not involve these tests so that it does not affect
the development and release process.

For the queueing issue mentioned before, after the self-hosted runners
switched back from github webhook scaling to load based scaling, it is back
to being stable. The issue was likely due to the webhook scaling on GitHub
side.

Regards,
Yi

[1] https://ci-beam.apache.org/view/LoadTests/
[2] https://ci-beam.apache.org/view/PerformanceTests/

Re: [Discuss] Idea to increase RC voting participation

[Danny McCormick via dev]

Looks like for some reason the workflow didn't trigger. This is running on
GitHub's hosted runners, so my best guess is an outage.

Looking at a more refined query, this year there have been 14 issues that
were missed by the automation (3 had their milestone manually removed) -
https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed+reason%3Acompleted+created%3A%3E2023-01-01
out
of 605 total -
https://github.com/apache/beam/issues?q=is%3Aissue+is%3Aclosed+reason%3Acompleted+created%3A%3E2023-01-01+
-
as best I can tell there were a small number of workflow flakes and then
GHA didn't correctly trigger a few.

If we wanted, we could set up some recurring automation to go through and
try to pick up the ones without milestones (or modify our existing
automation to be more tolerant to failures), but it doesn't seem super
urgent to me (feel free to disagree). I don't think this piece needs to be
perfect.

On Tue, Oct 24, 2023 at 2:40 PM Kenneth Knowles  wrote:

> Just grabbing one at random for an example,
> https://github.com/apache/beam/issues/28635 seems like it was closed as
> completed but not tagged.
>
> I'm happy to see that the bot reads the version from the repo to find the
> appropriate milestone, rather than using the nearest open one. Just
> recording that for the thread since I first read the description as the
> latter.
>
> Kenn
>
> On Tue, Oct 24, 2023 at 2:34 PM Danny McCormick via dev <
> dev@beam.apache.org> wrote:
>
>> We do tag issues to milestones when the issue is marked as "completed"
>> (as opposed to "not planned") -
>> https://github.com/apache/beam/blob/master/.github/workflows/assign_milestone.yml.
>> So I think using issues is probably about as accurate as using commits.
>>
>> > It looks like we have 820 with no milestone
>> https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed
>>
>> Most predate the automation, though maybe not all? Some of those may have
>> been closed as "not planned".
>>
>> > This could (should) be automatically discoverable. A (closed) issues is
>> associated with commits which are associated with a release.
>>
>> Today, we just tag issues to the upcoming milestone when they're closed.
>> In theory you could do something more sophisticated using linked commits,
>> but in practice people aren't clean enough about linking commits to issues.
>> Again, this is fixable by automation/enforcement, but I don't think it
>> actually gives us much value beyond what we have today.
>>
>> On Tue, Oct 24, 2023 at 1:54 PM Robert Bradshaw via dev <
>> dev@beam.apache.org> wrote:
>>
>>> On Tue, Oct 24, 2023 at 10:35 AM Kenneth Knowles 
>>> wrote:
>>>
 Tangentially related:

 Long ago, attaching an issue to a release was a mandatory step as part
 of closing. Now I think it is not. Is it automatically happening? It looks
 like we have 820 with no milestone
 https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed

>>>
>>> This could (should) be automatically discoverable. A (closed) issues is
>>> associated with commits which are associated with a release.
>>>
>>>
 On Tue, Oct 24, 2023 at 1:25 PM Chamikara Jayalath via dev <
 dev@beam.apache.org> wrote:

> +1 for going by the commits since this is what matters at the end of
> the day. Also, many issues may not get tagged correctly for a given 
> release
> due to either the contributor not tagging the issue or due to commits for
> the issue spanning multiple Beam releases.
>
> For example,
>
> For all commits in a given release RC:
>   * If we find a Github issue for the commit: add a notice to the
> Github issue
>   * Else: add the notice to a generic issue for the release including
> tags for the commit ID, PR author, and the committer who merged the PR.
>
> Thanks,
> Cham
>
>
>
>
> On Mon, Oct 23, 2023 at 11:49 AM Danny McCormick via dev <
> dev@beam.apache.org> wrote:
>
>> I'd probably vote to include both the issue filer and the
>> contributor. It is pretty equally straightforward - one way to do this
>> would be using all issues related to that release's milestone and
>> extracting the issue author and the issue closer.
>>
>> This does leave out the (unfortunately sizable) set of contributions
>> that don't have an associated issue; if we're worried about that, we 
>> could
>> always fall back to anyone with a commit in the last release who doesn't
>> have an associated issue (aka what I thought we were initially proposing
>> and what I think Airflow does today).
>>
>> I'm pretty much +1 on any sort of automation here, and it
>> certainly can come in stages :)
>>
>> On Mon, Oct 23, 2023 at 1:50 PM Johanna Öjeling via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Yes that's a good point to include also those who created the issue.
>>>
>>> On Mon, Oct 

Re: [Discuss] Idea to increase RC voting participation

[Kenneth Knowles]

Just grabbing one at random for an example,
https://github.com/apache/beam/issues/28635 seems like it was closed as
completed but not tagged.

I'm happy to see that the bot reads the version from the repo to find the
appropriate milestone, rather than using the nearest open one. Just
recording that for the thread since I first read the description as the
latter.

Kenn

On Tue, Oct 24, 2023 at 2:34 PM Danny McCormick via dev 
wrote:

> We do tag issues to milestones when the issue is marked as "completed" (as
> opposed to "not planned") -
> https://github.com/apache/beam/blob/master/.github/workflows/assign_milestone.yml.
> So I think using issues is probably about as accurate as using commits.
>
> > It looks like we have 820 with no milestone
> https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed
>
> Most predate the automation, though maybe not all? Some of those may have
> been closed as "not planned".
>
> > This could (should) be automatically discoverable. A (closed) issues is
> associated with commits which are associated with a release.
>
> Today, we just tag issues to the upcoming milestone when they're closed.
> In theory you could do something more sophisticated using linked commits,
> but in practice people aren't clean enough about linking commits to issues.
> Again, this is fixable by automation/enforcement, but I don't think it
> actually gives us much value beyond what we have today.
>
> On Tue, Oct 24, 2023 at 1:54 PM Robert Bradshaw via dev <
> dev@beam.apache.org> wrote:
>
>> On Tue, Oct 24, 2023 at 10:35 AM Kenneth Knowles  wrote:
>>
>>> Tangentially related:
>>>
>>> Long ago, attaching an issue to a release was a mandatory step as part
>>> of closing. Now I think it is not. Is it automatically happening? It looks
>>> like we have 820 with no milestone
>>> https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed
>>>
>>
>> This could (should) be automatically discoverable. A (closed) issues is
>> associated with commits which are associated with a release.
>>
>>
>>> On Tue, Oct 24, 2023 at 1:25 PM Chamikara Jayalath via dev <
>>> dev@beam.apache.org> wrote:
>>>
 +1 for going by the commits since this is what matters at the end of
 the day. Also, many issues may not get tagged correctly for a given release
 due to either the contributor not tagging the issue or due to commits for
 the issue spanning multiple Beam releases.

 For example,

 For all commits in a given release RC:
   * If we find a Github issue for the commit: add a notice to the
 Github issue
   * Else: add the notice to a generic issue for the release including
 tags for the commit ID, PR author, and the committer who merged the PR.

 Thanks,
 Cham




 On Mon, Oct 23, 2023 at 11:49 AM Danny McCormick via dev <
 dev@beam.apache.org> wrote:

> I'd probably vote to include both the issue filer and the contributor.
> It is pretty equally straightforward - one way to do this would be using
> all issues related to that release's milestone and extracting the issue
> author and the issue closer.
>
> This does leave out the (unfortunately sizable) set of contributions
> that don't have an associated issue; if we're worried about that, we could
> always fall back to anyone with a commit in the last release who doesn't
> have an associated issue (aka what I thought we were initially proposing
> and what I think Airflow does today).
>
> I'm pretty much +1 on any sort of automation here, and it
> certainly can come in stages :)
>
> On Mon, Oct 23, 2023 at 1:50 PM Johanna Öjeling via dev <
> dev@beam.apache.org> wrote:
>
>> Yes that's a good point to include also those who created the issue.
>>
>> On Mon, Oct 23, 2023, 19:18 Robert Bradshaw via dev <
>> dev@beam.apache.org> wrote:
>>
>>> On Mon, Oct 23, 2023 at 7:26 AM Danny McCormick via dev <
>>> dev@beam.apache.org> wrote:
>>>
 So to summarize, I think there's broad consensus (or at least lazy
 consensus) around the following:

 - (1) Updating our release email/guidelines to be more specific
 about what we mean by release validation/how to be helpful during this
 process. This includes both encouraging validation within each user's 
 own
 code base and encouraging people to document/share their process of
 validation and link it in the release spreadsheet.
 - (2) Doing something like what Airflow does (#29424
 ) and creating an
 issue asking people who have contributed to the current release to help
 validate their changes.

 I'm also +1 on doing both of these. The first bit (updating our
 guidelines) is relatively easy - it should just require updating
 

Re: [Discuss] Idea to increase RC voting participation

[Robert Bradshaw via dev]

On Tue, Oct 24, 2023 at 10:35 AM Kenneth Knowles  wrote:

> Tangentially related:
>
> Long ago, attaching an issue to a release was a mandatory step as part of
> closing. Now I think it is not. Is it automatically happening? It looks
> like we have 820 with no milestone
> https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed
>

This could (should) be automatically discoverable. A (closed) issues is
associated with commits which are associated with a release.


> On Tue, Oct 24, 2023 at 1:25 PM Chamikara Jayalath via dev <
> dev@beam.apache.org> wrote:
>
>> +1 for going by the commits since this is what matters at the end of the
>> day. Also, many issues may not get tagged correctly for a given release due
>> to either the contributor not tagging the issue or due to commits for the
>> issue spanning multiple Beam releases.
>>
>> For example,
>>
>> For all commits in a given release RC:
>>   * If we find a Github issue for the commit: add a notice to the Github
>> issue
>>   * Else: add the notice to a generic issue for the release including
>> tags for the commit ID, PR author, and the committer who merged the PR.
>>
>> Thanks,
>> Cham
>>
>>
>>
>>
>> On Mon, Oct 23, 2023 at 11:49 AM Danny McCormick via dev <
>> dev@beam.apache.org> wrote:
>>
>>> I'd probably vote to include both the issue filer and the contributor.
>>> It is pretty equally straightforward - one way to do this would be using
>>> all issues related to that release's milestone and extracting the issue
>>> author and the issue closer.
>>>
>>> This does leave out the (unfortunately sizable) set of contributions
>>> that don't have an associated issue; if we're worried about that, we could
>>> always fall back to anyone with a commit in the last release who doesn't
>>> have an associated issue (aka what I thought we were initially proposing
>>> and what I think Airflow does today).
>>>
>>> I'm pretty much +1 on any sort of automation here, and it certainly can
>>> come in stages :)
>>>
>>> On Mon, Oct 23, 2023 at 1:50 PM Johanna Öjeling via dev <
>>> dev@beam.apache.org> wrote:
>>>
 Yes that's a good point to include also those who created the issue.

 On Mon, Oct 23, 2023, 19:18 Robert Bradshaw via dev <
 dev@beam.apache.org> wrote:

> On Mon, Oct 23, 2023 at 7:26 AM Danny McCormick via dev <
> dev@beam.apache.org> wrote:
>
>> So to summarize, I think there's broad consensus (or at least lazy
>> consensus) around the following:
>>
>> - (1) Updating our release email/guidelines to be more specific about
>> what we mean by release validation/how to be helpful during this process.
>> This includes both encouraging validation within each user's own code 
>> base
>> and encouraging people to document/share their process of validation and
>> link it in the release spreadsheet.
>> - (2) Doing something like what Airflow does (#29424
>> ) and creating an
>> issue asking people who have contributed to the current release to help
>> validate their changes.
>>
>> I'm also +1 on doing both of these. The first bit (updating our
>> guidelines) is relatively easy - it should just require updating
>> https://github.com/apache/beam/blob/master/contributor-docs/release-guide.md#vote-and-validate-the-release-candidate
>> .
>>
>> I took a look at the second piece (copying what Airflow does) to see
>> if we could just copy their automation, but it looks like it's tied
>> to airflow breeze
>> 
>> (their repo-specific automation tooling), so we'd probably need to build
>> the automation ourselves. It shouldn't be terrible, basically we'd want a
>> GitHub Action that compares the current release tag with the last release
>> tag, grabs all the commits in between, parses them to get the author, and
>> creates an issue with that data, but it does represent more effort than
>> just updating a markdown file. There might even be an existing Action 
>> that
>> can help with this, I haven't looked too hard.
>>
>
> I was thinking along the lines of a script that would scrape the
> issues resolved in a given release and add a comment to them noting that
> the change is in release N and encouraging (with clear instructions) how
> this can be validated. Creating a "validate this release" issue with all
> "contributing" participants could be an interesting way to do this as 
> well.
> (I think it'd be valuable to get those who filed the issue, not just those
> who fixed it, to validate.)
>
>
>> As our next release manager, I'm happy to review PRs for either of
>> these if anyone wants to volunteer to help out. If not, I'm happy to 
>> update
>> the guidelines, but I probably won't have 

Re: [Discuss] Idea to increase RC voting participation

[Kenneth Knowles]

Tangentially related:

Long ago, attaching an issue to a release was a mandatory step as part of
closing. Now I think it is not. Is it automatically happening? It looks
like we have 820 with no milestone
https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed

Kenn

On Tue, Oct 24, 2023 at 1:25 PM Chamikara Jayalath via dev <
dev@beam.apache.org> wrote:

> +1 for going by the commits since this is what matters at the end of the
> day. Also, many issues may not get tagged correctly for a given release due
> to either the contributor not tagging the issue or due to commits for the
> issue spanning multiple Beam releases.
>
> For example,
>
> For all commits in a given release RC:
>   * If we find a Github issue for the commit: add a notice to the Github
> issue
>   * Else: add the notice to a generic issue for the release including tags
> for the commit ID, PR author, and the committer who merged the PR.
>
> Thanks,
> Cham
>
>
>
>
> On Mon, Oct 23, 2023 at 11:49 AM Danny McCormick via dev <
> dev@beam.apache.org> wrote:
>
>> I'd probably vote to include both the issue filer and the contributor. It
>> is pretty equally straightforward - one way to do this would be using all
>> issues related to that release's milestone and extracting the issue author
>> and the issue closer.
>>
>> This does leave out the (unfortunately sizable) set of contributions that
>> don't have an associated issue; if we're worried about that, we could
>> always fall back to anyone with a commit in the last release who doesn't
>> have an associated issue (aka what I thought we were initially proposing
>> and what I think Airflow does today).
>>
>> I'm pretty much +1 on any sort of automation here, and it certainly can
>> come in stages :)
>>
>> On Mon, Oct 23, 2023 at 1:50 PM Johanna Öjeling via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Yes that's a good point to include also those who created the issue.
>>>
>>> On Mon, Oct 23, 2023, 19:18 Robert Bradshaw via dev 
>>> wrote:
>>>
 On Mon, Oct 23, 2023 at 7:26 AM Danny McCormick via dev <
 dev@beam.apache.org> wrote:

> So to summarize, I think there's broad consensus (or at least lazy
> consensus) around the following:
>
> - (1) Updating our release email/guidelines to be more specific about
> what we mean by release validation/how to be helpful during this process.
> This includes both encouraging validation within each user's own code base
> and encouraging people to document/share their process of validation and
> link it in the release spreadsheet.
> - (2) Doing something like what Airflow does (#29424
> ) and creating an
> issue asking people who have contributed to the current release to help
> validate their changes.
>
> I'm also +1 on doing both of these. The first bit (updating our
> guidelines) is relatively easy - it should just require updating
> https://github.com/apache/beam/blob/master/contributor-docs/release-guide.md#vote-and-validate-the-release-candidate
> .
>
> I took a look at the second piece (copying what Airflow does) to see
> if we could just copy their automation, but it looks like it's tied
> to airflow breeze
> 
> (their repo-specific automation tooling), so we'd probably need to build
> the automation ourselves. It shouldn't be terrible, basically we'd want a
> GitHub Action that compares the current release tag with the last release
> tag, grabs all the commits in between, parses them to get the author, and
> creates an issue with that data, but it does represent more effort than
> just updating a markdown file. There might even be an existing Action that
> can help with this, I haven't looked too hard.
>

 I was thinking along the lines of a script that would scrape the issues
 resolved in a given release and add a comment to them noting that the
 change is in release N and encouraging (with clear instructions) how this
 can be validated. Creating a "validate this release" issue with all
 "contributing" participants could be an interesting way to do this as well.
 (I think it'd be valuable to get those who filed the issue, not just those
 who fixed it, to validate.)


> As our next release manager, I'm happy to review PRs for either of
> these if anyone wants to volunteer to help out. If not, I'm happy to 
> update
> the guidelines, but I probably won't have time to add the commit 
> inspection
> tooling (I'm planning on throwing any extra time towards continuing to
> automate release candidate creation which is currently a more impactful
> problem IMO). I would very much like it if both of these things happened
> though :)
>
> Thanks,
> Danny
>
> On Mon, 

Re: [Discuss] Idea to increase RC voting participation

[Chamikara Jayalath via dev]

+1 for going by the commits since this is what matters at the end of the
day. Also, many issues may not get tagged correctly for a given release due
to either the contributor not tagging the issue or due to commits for the
issue spanning multiple Beam releases.

For example,

For all commits in a given release RC:
  * If we find a Github issue for the commit: add a notice to the Github
issue
  * Else: add the notice to a generic issue for the release including tags
for the commit ID, PR author, and the committer who merged the PR.

Thanks,
Cham




On Mon, Oct 23, 2023 at 11:49 AM Danny McCormick via dev <
dev@beam.apache.org> wrote:

> I'd probably vote to include both the issue filer and the contributor. It
> is pretty equally straightforward - one way to do this would be using all
> issues related to that release's milestone and extracting the issue author
> and the issue closer.
>
> This does leave out the (unfortunately sizable) set of contributions that
> don't have an associated issue; if we're worried about that, we could
> always fall back to anyone with a commit in the last release who doesn't
> have an associated issue (aka what I thought we were initially proposing
> and what I think Airflow does today).
>
> I'm pretty much +1 on any sort of automation here, and it certainly can
> come in stages :)
>
> On Mon, Oct 23, 2023 at 1:50 PM Johanna Öjeling via dev <
> dev@beam.apache.org> wrote:
>
>> Yes that's a good point to include also those who created the issue.
>>
>> On Mon, Oct 23, 2023, 19:18 Robert Bradshaw via dev 
>> wrote:
>>
>>> On Mon, Oct 23, 2023 at 7:26 AM Danny McCormick via dev <
>>> dev@beam.apache.org> wrote:
>>>
 So to summarize, I think there's broad consensus (or at least lazy
 consensus) around the following:

 - (1) Updating our release email/guidelines to be more specific about
 what we mean by release validation/how to be helpful during this process.
 This includes both encouraging validation within each user's own code base
 and encouraging people to document/share their process of validation and
 link it in the release spreadsheet.
 - (2) Doing something like what Airflow does (#29424
 ) and creating an
 issue asking people who have contributed to the current release to help
 validate their changes.

 I'm also +1 on doing both of these. The first bit (updating our
 guidelines) is relatively easy - it should just require updating
 https://github.com/apache/beam/blob/master/contributor-docs/release-guide.md#vote-and-validate-the-release-candidate
 .

 I took a look at the second piece (copying what Airflow does) to see if
 we could just copy their automation, but it looks like it's tied to
 airflow breeze
 
 (their repo-specific automation tooling), so we'd probably need to build
 the automation ourselves. It shouldn't be terrible, basically we'd want a
 GitHub Action that compares the current release tag with the last release
 tag, grabs all the commits in between, parses them to get the author, and
 creates an issue with that data, but it does represent more effort than
 just updating a markdown file. There might even be an existing Action that
 can help with this, I haven't looked too hard.

>>>
>>> I was thinking along the lines of a script that would scrape the issues
>>> resolved in a given release and add a comment to them noting that the
>>> change is in release N and encouraging (with clear instructions) how this
>>> can be validated. Creating a "validate this release" issue with all
>>> "contributing" participants could be an interesting way to do this as well.
>>> (I think it'd be valuable to get those who filed the issue, not just those
>>> who fixed it, to validate.)
>>>
>>>
 As our next release manager, I'm happy to review PRs for either of
 these if anyone wants to volunteer to help out. If not, I'm happy to update
 the guidelines, but I probably won't have time to add the commit inspection
 tooling (I'm planning on throwing any extra time towards continuing to
 automate release candidate creation which is currently a more impactful
 problem IMO). I would very much like it if both of these things happened
 though :)

 Thanks,
 Danny

 On Mon, Oct 23, 2023 at 10:05 AM XQ Hu  wrote:

> +1. This is a great idea to try. @Danny McCormick
>  FYI as our next release manager.
>
> On Wed, Oct 18, 2023 at 2:30 PM Johanna Öjeling via dev <
> dev@beam.apache.org> wrote:
>
>> When I have contributed to Apache Airflow, they have tagged all
>> contributors concerned in a GitHub issue when the RC is available and 
>> asked
>> us to validate it. Example: #29424
>> 

Beam High Priority Issue Report (46)

[beamactions]

This is your daily summary of Beam's current high priority issues that may need 
attention.

See https://beam.apache.org/contribute/issue-priorities for the meaning and 
expectations around issue priorities.

Unassigned P1 Issues:

https://github.com/apache/beam/issues/29099 [Bug]: FnAPI Java SDK Harness 
doesn't update user counters in OnTimer callback functions
https://github.com/apache/beam/issues/29076 [Failing Test]: Python ARM 
PostCommit failing after #28385
https://github.com/apache/beam/issues/29022 [Failing Test]: Python Github 
actions tests are failing due to update of pip 
https://github.com/apache/beam/issues/28760 [Bug]: EFO Kinesis IO reader 
provided by apache beam does not pick the event time for watermarking
https://github.com/apache/beam/issues/28703 [Failing Test]: Building a wheel 
for integration tests sometimes times out
https://github.com/apache/beam/issues/28383 [Failing Test]: 
org.apache.beam.runners.dataflow.worker.StreamingDataflowWorkerTest.testMaxThreadMetric
https://github.com/apache/beam/issues/28339 Fix failing 
"beam_PostCommit_XVR_GoUsingJava_Dataflow" job
https://github.com/apache/beam/issues/28326 Bug: 
apache_beam.io.gcp.pubsublite.ReadFromPubSubLite not working
https://github.com/apache/beam/issues/28142 [Bug]: [Go SDK] Memory seems to be 
leaking on 2.49.0 with Dataflow
https://github.com/apache/beam/issues/27892 [Bug]: ignoreUnknownValues not 
working when using CreateDisposition.CREATE_IF_NEEDED 
https://github.com/apache/beam/issues/27648 [Bug]: Python SDFs (e.g. 
PeriodicImpulse) running in Flink and polling using tracker.defer_remainder 
have checkpoint size growing indefinitely 
https://github.com/apache/beam/issues/27616 [Bug]: Unable to use 
applyRowMutations() in bigquery IO apache beam java
https://github.com/apache/beam/issues/27486 [Bug]: Read from datastore with 
inequality filters
https://github.com/apache/beam/issues/27314 [Failing Test]: 
bigquery.StorageApiSinkCreateIfNeededIT.testCreateManyTables[1]
https://github.com/apache/beam/issues/27238 [Bug]: Window trigger has lag when 
using Kafka and GroupByKey on Dataflow Runner
https://github.com/apache/beam/issues/26981 [Bug]: Getting an error related to 
SchemaCoder after upgrading to 2.48
https://github.com/apache/beam/issues/26911 [Bug]: UNNEST ARRAY with a nested 
ROW (described below)
https://github.com/apache/beam/issues/26343 [Bug]: 
apache_beam.io.gcp.bigquery_read_it_test.ReadAllBQTests.test_read_queries is 
flaky
https://github.com/apache/beam/issues/26329 [Bug]: BigQuerySourceBase does not 
propagate a Coder to AvroSource
https://github.com/apache/beam/issues/26041 [Bug]: Unable to create 
exactly-once Flink pipeline with stream source and file sink
https://github.com/apache/beam/issues/24776 [Bug]: Race condition in Python SDK 
Harness ProcessBundleProgress
https://github.com/apache/beam/issues/24389 [Failing Test]: 
HadoopFormatIOElasticTest.classMethod ExceptionInInitializerError 
ContainerFetchException
https://github.com/apache/beam/issues/24313 [Flaky]: 
apache_beam/runners/portability/portable_runner_test.py::PortableRunnerTestWithSubprocesses::test_pardo_state_with_custom_key_coder
https://github.com/apache/beam/issues/23944  beam_PreCommit_Python_Cron 
regularily failing - test_pardo_large_input flaky
https://github.com/apache/beam/issues/23709 [Flake]: Spark batch flakes in 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElement and 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInStartBundle
https://github.com/apache/beam/issues/23525 [Bug]: Default PubsubMessage coder 
will drop message id and orderingKey
https://github.com/apache/beam/issues/22913 [Bug]: 
beam_PostCommit_Java_ValidatesRunner_Flink is flakes in 
org.apache.beam.sdk.transforms.GroupByKeyTest$BasicTests.testAfterProcessingTimeContinuationTriggerUsingState
https://github.com/apache/beam/issues/22605 [Bug]: Beam Python failure for 
dataflow_exercise_metrics_pipeline_test.ExerciseMetricsPipelineTest.test_metrics_it
https://github.com/apache/beam/issues/21714 
PulsarIOTest.testReadFromSimpleTopic is very flaky
https://github.com/apache/beam/issues/21706 Flaky timeout in github Python unit 
test action 
StatefulDoFnOnDirectRunnerTest.test_dynamic_timer_clear_then_set_timer
https://github.com/apache/beam/issues/21643 FnRunnerTest with non-trivial 
(order 1000 elements) numpy input flakes in non-cython environment
https://github.com/apache/beam/issues/21476 WriteToBigQuery Dynamic table 
destinations returns wrong tableId
https://github.com/apache/beam/issues/21469 beam_PostCommit_XVR_Flink flaky: 
Connection refused
https://github.com/apache/beam/issues/21424 Java VR (Dataflow, V2, Streaming) 
failing: ParDoTest$TimestampTests/OnWindowExpirationTests
https://github.com/apache/beam/issues/21262 Python AfterAny, AfterAll do not 
follow spec
https://github.com/apache/beam/issues/21260 Python DirectRunner does not emit 
data at GC time
https://github.com/apache/beam/issues/21121