Re: [beam-starter-typescript]: Missing place to create issue

2023-07-06 Thread Robert Bradshaw via dev 
On Wed, Jun 14, 2023 at 2:05 PM Austin Bennett  wrote:

> A few additional thoughts:
>
> *  @Anyone --> Should each starter repo allow issues?  Or, better to file
> issues in https://github.com/apache/beam/issues ?
>

I'm on the fence. It would make sense to allow issues here, but I'm also
concerned that they might not have sufficient visibility in the individual
starter project repos.


> * @david-kh...@hotmail.com -- I'd say in general PRs are likely welcome.
>

+1, for sure.


> * Seems like Contributing.md should get updated.  The text linking to
> issues, actually takes people to PRs.
>
>
>
> On Wed, Jun 14, 2023 at 10:26 AM Kerry Donny-Clark via dev <
> dev@beam.apache.org> wrote:
>
>> Jack may also be able to help you create an issue.
>> Kerry
>>
>> On Wed, Jun 14, 2023, 1:09 PM XQ Hu via dev  wrote:
>>
>>> I believe Robert is the owner for that project.
>>>
>>> On Mon, Jun 12, 2023 at 11:30 PM david-kh...@hotmail.com <
>>> david-kh...@hotmail.com> wrote:
>>>
 Hi Beam community,



 I am David and new to the community. After tried to tweak some code
 from beam-starter-ts, I have found some issues and want to raise. But there
 is no way I can create an Github issue in the same project

 apache/beam-starter-typescript: Apache beam (github.com)
 .



 I also double check the Contribute.md and get no idea still.



 Would you mind guide me to the right path?



 Regards,

 David L.

>>>

Re: [DISCUSS] Enable Github Discussions?

2023-07-06 Thread Robert Burke 
I'm -1 on GitHub discussions.

If anything the user can just file a GitHub issue for the same purpose, if
they prefer the GitHub interface over emails. In theory, GHDiscussions can
be better for very active topics, but honestly I don't think we have that
sort of throughput.

 Having payed attention to a few uses of the Go Programming Language use of
GitHub features, i found the Discussions lead to *more* repetitive threads
and points, since folks are emboldened to not pay attention outside of
their local thread in the discussion.

I can't see much of a meaningful difference between them and using the
Apache Slack instance, which can also have threaded micro discussions.

On Thu, Jul 6, 2023, 11:07 AM Robert Bradshaw via dev 
wrote:

> I'm also -1 on introducing another forum, and concur with Alexey that
> mailing lists are a (required) deep part of the culture for apache
> projects.
>
> If there's something qualitatively and significantly different about
> discussions that makes it a better fit, I would consider it. (E.g. IMHO the
> structure/format of stack overflow lends itself much better to scalable
> user support than a mailing list, which is why it makes sense to be there.)
> The statement about "folks to get[ting] unblocked on small/medium
> implementation blocker" is important, and we should definitely encourage
> people to more actively use the existing lists for this purpose rather than
> having out-of-band discussions when possible which will be helpful to the
> larger community. (Not seeing how this is unique to GH Discussions though.)
>
> (I'm also skeptical of "GH Discussions is more discoverable and
> approachable for new users and contributors." I definitely think it makes
> sense to meet users where they are, but while I know many developers that
> don't actively use github (some don't even have an account), I don't
> (personally) don't know any that don't have an email address which is a
> good lower common denominator. But maybe that just dates me...)
>
>
>
>
>
>
>
> On Wed, Jul 5, 2023 at 7:22 AM Jack McCluskey via dev 
> wrote:
>
>> Also going to be -1 on this one, I'm not sure we pick anything up from
>> adding a forum apart from adding another place that needs to be checked.
>>
>> On Tue, Jul 4, 2023 at 4:03 AM Jan Lukavský  wrote:
>>
>>> -1
>>>
>>> Totally agree with Byron and Alexey.
>>>
>>>  Jan
>>> On 7/3/23 21:18, Byron Ellis via dev wrote:
>>>
>>> -1. This just leads to needless fragmentation not to mention being at
>>> the mercy of a specific technology provider.
>>>
>>> On Mon, Jul 3, 2023 at 11:39 AM XQ Hu via dev 
>>> wrote:
>>>
 +1 with GH discussion.
 If Airflow can do this https://github.com/apache/airflow/discussions,
 I think we can do this as well.

 On Mon, Jul 3, 2023 at 9:51 AM Alexey Romanenko <
 aromanenko@gmail.com> wrote:

> -1
> I understand that for some people, who maybe are not very familiar
> with ASF and its “Apache Way” [1], it may sound a bit obsolete but mailing
> lists are one of the key things of every ASF project which Apache Beam is.
> Having user@, dev@ and commits@ lists are required for ASF project to
> maintain the open discussions that are publicly accessible and archived in
> the same way for all ASF projects.
>
> I just wanted to remind a key motto at Apache Software Foundation is:
>   *“If it didn't happen on the mailing list, it didn't happen.”*
>
> —
> Alexey
>
> [1] https://apache.org/theapacheway/index.html
>
> On 1 Jul 2023, at 19:54, Anand Inguva via dev 
> wrote:
>
> +1 for GitHub discussions as well. But I am also little concerned
> about multiple places for discussions. As Danny said, if we have a good
> plan on how to move forward on how/when to archive the current mailing
> list, that would be great.
>
> Thanks,
> Anand
>
> On Sat, Jul 1, 2023, 3:21 AM Damon Douglas 
> wrote:
>
>> I'm very strong +1 for replacing the use of Email with GitHub
>> Discussions. Thank you for bringing this up.
>>
>> On Fri, Jun 30, 2023 at 7:38 AM Danny McCormick via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Thanks for starting this discussion!
>>>
>>> I'm a weak -1 for this proposal. While I think that GH Discussions
>>> can be a good forum, I think most of the things that Discussions do are
>>> covered by some combination of the dev/user lists and GitHub issues, and
>>> the net outcome of this will be creating one more forum to pay attention
>>> to. I know in the past we've had a hard time keeping up with Stack 
>>> overflow
>>> questions for a similar reason. With that said, I'm not opposed to 
>>> trying
>>> it out and experimenting as long as we have (a) clear criteria for
>>> understanding if the change is effective or not (can be subjective), 
>>> (b) a
>>> clear idea of when we'd revisit the discussion, and (c) a

Re: [DISCUSS] Enable Github Discussions?

2023-07-06 Thread Robert Bradshaw via dev 
I'm also -1 on introducing another forum, and concur with Alexey that
mailing lists are a (required) deep part of the culture for apache
projects.

If there's something qualitatively and significantly different about
discussions that makes it a better fit, I would consider it. (E.g. IMHO the
structure/format of stack overflow lends itself much better to scalable
user support than a mailing list, which is why it makes sense to be there.)
The statement about "folks to get[ting] unblocked on small/medium
implementation blocker" is important, and we should definitely encourage
people to more actively use the existing lists for this purpose rather than
having out-of-band discussions when possible which will be helpful to the
larger community. (Not seeing how this is unique to GH Discussions though.)

(I'm also skeptical of "GH Discussions is more discoverable and
approachable for new users and contributors." I definitely think it makes
sense to meet users where they are, but while I know many developers that
don't actively use github (some don't even have an account), I don't
(personally) don't know any that don't have an email address which is a
good lower common denominator. But maybe that just dates me...)







On Wed, Jul 5, 2023 at 7:22 AM Jack McCluskey via dev 
wrote:

> Also going to be -1 on this one, I'm not sure we pick anything up from
> adding a forum apart from adding another place that needs to be checked.
>
> On Tue, Jul 4, 2023 at 4:03 AM Jan Lukavský  wrote:
>
>> -1
>>
>> Totally agree with Byron and Alexey.
>>
>>  Jan
>> On 7/3/23 21:18, Byron Ellis via dev wrote:
>>
>> -1. This just leads to needless fragmentation not to mention being at the
>> mercy of a specific technology provider.
>>
>> On Mon, Jul 3, 2023 at 11:39 AM XQ Hu via dev 
>> wrote:
>>
>>> +1 with GH discussion.
>>> If Airflow can do this https://github.com/apache/airflow/discussions, I
>>> think we can do this as well.
>>>
>>> On Mon, Jul 3, 2023 at 9:51 AM Alexey Romanenko <
>>> aromanenko@gmail.com> wrote:
>>>
 -1
 I understand that for some people, who maybe are not very familiar with
 ASF and its “Apache Way” [1], it may sound a bit obsolete but mailing lists
 are one of the key things of every ASF project which Apache Beam is. Having
 user@, dev@ and commits@ lists are required for ASF project to
 maintain the open discussions that are publicly accessible and archived in
 the same way for all ASF projects.

 I just wanted to remind a key motto at Apache Software Foundation is:
   *“If it didn't happen on the mailing list, it didn't happen.”*

 —
 Alexey

 [1] https://apache.org/theapacheway/index.html

 On 1 Jul 2023, at 19:54, Anand Inguva via dev 
 wrote:

 +1 for GitHub discussions as well. But I am also little concerned about
 multiple places for discussions. As Danny said, if we have a good plan on
 how to move forward on how/when to archive the current mailing list, that
 would be great.

 Thanks,
 Anand

 On Sat, Jul 1, 2023, 3:21 AM Damon Douglas 
 wrote:

> I'm very strong +1 for replacing the use of Email with GitHub
> Discussions. Thank you for bringing this up.
>
> On Fri, Jun 30, 2023 at 7:38 AM Danny McCormick via dev <
> dev@beam.apache.org> wrote:
>
>> Thanks for starting this discussion!
>>
>> I'm a weak -1 for this proposal. While I think that GH Discussions
>> can be a good forum, I think most of the things that Discussions do are
>> covered by some combination of the dev/user lists and GitHub issues, and
>> the net outcome of this will be creating one more forum to pay attention
>> to. I know in the past we've had a hard time keeping up with Stack 
>> overflow
>> questions for a similar reason. With that said, I'm not opposed to trying
>> it out and experimenting as long as we have (a) clear criteria for
>> understanding if the change is effective or not (can be subjective), (b) 
>> a
>> clear idea of when we'd revisit the discussion, and (c) a clear path to
>> rollback the decision without it being *too *much work (this might
>> mean something like disabling future discussions and keeping the history 
>> or
>> somehow moving the history to the dev or user list). If we do this, I 
>> also
>> think we should update https://beam.apache.org/community/contact-us/
>> with a clear taxonomy of what goes where (this is what I'm unsure of
>> today).
>>
>> FWIW, if we were proposing cutting either the user list or both the
>> user and dev list in favor of discussions, I would be +1. I do think the
>> advantages of discussions over email are real (threaded, easy to convert
>> to/from issues, markdown, one place for all things Beam).
>>
>> Thanks,
>> Danny
>>
>> On Fri, Jun 30, 2023 at 10:23 AM Svetak Sundhar via dev <
>>

Discover the newest data trends at Virtual Beam Summit 2023

2023-07-06 Thread Carolina Escobar 
[image: Beam Summit Virtual] 

Hello there, data enthusiasts!


We have some fantastic news to share: the *Virtual Beam Summit* is
happening from July 18 to 20th, 2023, and registration is now OPEN! Whether
you couldn't make it to the in-person event or missed out on some
mind-blowing sessions, this is the moment to learn all the latest trends in
data! 


Register Now 

The online experience will let you *watch ALL the sessions* from Beam
Summit in-person edition and will allow you to connect with speakers and
fellow participants from every corner of the globe.

With our live interaction feature, you can be part of the action, ask
burning questions, and share your own thoughts with our global community.

*Take a quick peek at our speaker line-up:*


Here are some of our sessions:

   -

   *Cross-language JdbcIO enabled by Beam portable schemas*
   Yi Hu shares the experience of the development and use cases enabled by
   the significant improvement in both features and performance in Beam
   v2.42.0, Beam Python SDK's JdbcIO, and the underlying Beam portable schema.
   -

   *Use Apache Beam to build Machine Learning Feature System at Affirm*
   Hao Xu explores how Affirm uses Apache Beam to build a unified
   transformation engine within a machine-learning feature store,
   demonstrating how to leverage Apache Beam to enable machine learning in
   various business cases, such as fraud detection, underwriting, and growth
   -

   *Meeting Security Requirements for Apache Beam Pipelines on Google Cloud*
   Lorenzo Caggioni identifies a reference architecture to accomplish
   requirements such as role separation and least privileges, private
   resources, and encryption of customer data on a Google Cloud Platform
   environment.
   -

   *Oops I *actually* wrote a Portable Beam Runner in Go*
   Robert Burke, through a demo, code walkthrough, and testing advice,
   covers what the new runner can do and why you might find it useful.
   -

   *Simplifying Speech-to-Text Processing with Apache Beam and Redis*
   Pramod Rao and Prateek Sheel will present their design journey to solve
   a complex speech-to-text processing problem in Apache Beam by leveraging
   Redis, a simple and efficient external persistent state
   -

   *Introduction to Clustering in Apache Beam*
   Jasper Van den Bossche dives into all the steps involved in one of the
   big challenges when working with per entity: training. These steps may
   include: Data ingestion from different sources, processing data in various
   formats and varying quality, inference of the different models or post
   processing the results so they can be presented to the end user in a
   waythat is easy to understand.
   -

   *Developing (experimental) Rust SDKs and a Beam engine for IoT devices*
   Sho Nakatani proposes the making of SpringQL as a Beam engine and
   discusses the work done to change SpringQL's API from incomplete streaming
   SQL to the Beam Model


Check out the Program 
Register Now 
[image: Tw]  [image: Yt]
 [image: In]

[VOTE] Release 2.49.0, release candidate #1

2023-07-06 Thread Yi Hu via dev 
Hi everyone,
Please review and vote on the release candidate #1 for the version 2.49.0,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)


Reviewers are encouraged to test their own use cases with the release
candidate, and vote +1 if
no issues are found. Only PMC member votes will count towards the final
vote, but votes from all
community members is encouraged and helpful for finding regressions; you
can either test your own
use cases or use cases from the validation sheet [10].

The complete staging area is available for your review, which includes:
* GitHub Release notes [1],
* the official Apache source release to be deployed to dist.apache.org [2],
which is signed with the key with
fingerprint either CB6974C8170405CB (y...@apache.org) or D20316F712213422
(GitHub Action automated) [3],
* all artifacts to be deployed to the Maven Central Repository [4],
* source code tag "v2.49.0-RC1" [5],
* website pull request listing the release [6], the blog post [6], and
publishing the API reference manual [7].
* Java artifacts were built with Gradle GRADLE_VERSION and OpenJDK/Oracle
JDK JDK_VERSION.
* Python artifacts are deployed along with the source release to the
dist.apache.org [2] and PyPI [8].
* Go artifacts and documentation are available at pkg.go.dev [9]
* Validation sheet with a tab for 2.49.0 release to help with validation
[10].
* Docker images published to Docker Hub [11].
* PR to run tests against release branch [12].

The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.

For guidelines on how to try the release in your projects, check out our
blog post at /blog/validate-beam-release/.

Thanks,
Release Manager

[1] https://github.com/apache/beam/milestone/13
[2] https://dist.apache.org/repos/dist/dev/beam/2.49.0/
[3] https://dist.apache.org/repos/dist/release/beam/KEYS
[4] https://repository.apache.org/content/repositories/orgapachebeam-1348/
[5] https://github.com/apache/beam/tree/v2.49.0-RC1
[6] https://github.com/apache/beam/pull/27374
[7] https://github.com/apache/beam-site/pull/646
[8] https://pypi.org/project/apache-beam/2.49.0rc1/
[9]
https://pkg.go.dev/github.com/apache/beam/sdks/v2@v2.49.0-RC1/go/pkg/beam
[10]
https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=934901728
[11] https://hub.docker.com/search?q=apache%2Fbeam=image
[12] https://github.com/apache/beam/pull/27307

-- 

Yi Hu, (he/him/his)

Software Engineer

Re: [DISCUSS] Enable Github Discussions?

2023-07-06 Thread Svetak Sundhar via dev 
Thanks all for your perspectives, and Alexey for pointing out that we must
keep the dev and user lists regardless. Looks like we don't need to take
any further action here.

For the sake of discussion, I'd be curious to hear perspectives of those
that are part of the Airflow community or another community where both
user/dev lists and GH Discussions are used. Specifically, is there is any
sort of value add or is it just a maintenance burden?



Svetak Sundhar

  Data Engineer
s vetaksund...@google.com



On Wed, Jul 5, 2023 at 10:21 AM Jack McCluskey via dev 
wrote:

> Also going to be -1 on this one, I'm not sure we pick anything up from
> adding a forum apart from adding another place that needs to be checked.
>
> On Tue, Jul 4, 2023 at 4:03 AM Jan Lukavský  wrote:
>
>> -1
>>
>> Totally agree with Byron and Alexey.
>>
>>  Jan
>> On 7/3/23 21:18, Byron Ellis via dev wrote:
>>
>> -1. This just leads to needless fragmentation not to mention being at the
>> mercy of a specific technology provider.
>>
>> On Mon, Jul 3, 2023 at 11:39 AM XQ Hu via dev 
>> wrote:
>>
>>> +1 with GH discussion.
>>> If Airflow can do this https://github.com/apache/airflow/discussions, I
>>> think we can do this as well.
>>>
>>> On Mon, Jul 3, 2023 at 9:51 AM Alexey Romanenko <
>>> aromanenko@gmail.com> wrote:
>>>
 -1
 I understand that for some people, who maybe are not very familiar with
 ASF and its “Apache Way” [1], it may sound a bit obsolete but mailing lists
 are one of the key things of every ASF project which Apache Beam is. Having
 user@, dev@ and commits@ lists are required for ASF project to
 maintain the open discussions that are publicly accessible and archived in
 the same way for all ASF projects.

 I just wanted to remind a key motto at Apache Software Foundation is:
   *“If it didn't happen on the mailing list, it didn't happen.”*

 —
 Alexey

 [1] https://apache.org/theapacheway/index.html

 On 1 Jul 2023, at 19:54, Anand Inguva via dev 
 wrote:

 +1 for GitHub discussions as well. But I am also little concerned about
 multiple places for discussions. As Danny said, if we have a good plan on
 how to move forward on how/when to archive the current mailing list, that
 would be great.

 Thanks,
 Anand

 On Sat, Jul 1, 2023, 3:21 AM Damon Douglas 
 wrote:

> I'm very strong +1 for replacing the use of Email with GitHub
> Discussions. Thank you for bringing this up.
>
> On Fri, Jun 30, 2023 at 7:38 AM Danny McCormick via dev <
> dev@beam.apache.org> wrote:
>
>> Thanks for starting this discussion!
>>
>> I'm a weak -1 for this proposal. While I think that GH Discussions
>> can be a good forum, I think most of the things that Discussions do are
>> covered by some combination of the dev/user lists and GitHub issues, and
>> the net outcome of this will be creating one more forum to pay attention
>> to. I know in the past we've had a hard time keeping up with Stack 
>> overflow
>> questions for a similar reason. With that said, I'm not opposed to trying
>> it out and experimenting as long as we have (a) clear criteria for
>> understanding if the change is effective or not (can be subjective), (b) 
>> a
>> clear idea of when we'd revisit the discussion, and (c) a clear path to
>> rollback the decision without it being *too *much work (this might
>> mean something like disabling future discussions and keeping the history 
>> or
>> somehow moving the history to the dev or user list). If we do this, I 
>> also
>> think we should update https://beam.apache.org/community/contact-us/
>> with a clear taxonomy of what goes where (this is what I'm unsure of
>> today).
>>
>> FWIW, if we were proposing cutting either the user list or both the
>> user and dev list in favor of discussions, I would be +1. I do think the
>> advantages of discussions over email are real (threaded, easy to convert
>> to/from issues, markdown, one place for all things Beam).
>>
>> Thanks,
>> Danny
>>
>> On Fri, Jun 30, 2023 at 10:23 AM Svetak Sundhar via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to start a discussion to gauge interest on enabling Github
>>> Discussions  in
>>> Apache Beam.
>>>
>>> Pros:
>>> + GH Discussions allows for folks to get unblocked on small/medium
>>> implementation blocker (Google employees can often get this help by
>>> scheduling a call with teammates whereas there is a larger barrier for
>>> non-Google employees to get this help).
>>> + On the above point, more visibility into the development blockers
>>> that others have previously faced.
>>> + GH Discussions is more discoverable and approachable for new users
>>> and

Beam High Priority Issue Report (40)

2023-07-06 Thread 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/27320 [Failing Test]: 
beam_Release_Gradle_Build permared
https://github.com/apache/beam/issues/27315 [Failing Test]: PubsubReadIT 
timeout pollForResultForDuration
https://github.com/apache/beam/issues/27314 [Failing Test]: 
bigquery.StorageApiSinkCreateIfNeededIT.testCreateManyTables[1]
https://github.com/apache/beam/issues/27312 [Bug]: JmsIO create connection 
based on the number of threads
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/26969 [Failing Test]: Python PostCommit 
is failing due to exceeded rate limits
https://github.com/apache/beam/issues/26911 [Bug]: UNNEST ARRAY with a nested 
ROW (described below)
https://github.com/apache/beam/issues/26547 [Failing Test]: 
beam_PostCommit_Java_DataflowV2
https://github.com/apache/beam/issues/26354 [Bug]: BigQueryIO direct read not 
reading all rows when set --setEnableBundling=true
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/25975 [Bug]: Reducing parallelism in 
FlinkRunner leads to a data loss
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/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/21708 beam_PostCommit_Java_DataflowV2, 
testBigQueryStorageWrite30MProto failing consistently
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 
apache_beam.examples.streaming_wordcount_it_test.StreamingWordCountIT.test_streaming_wordcount_it
 flakey
https://github.com/apache/beam/issues/21104 Flaky: 
apache_beam.runners.portability.fn_api_runner.fn_runner_test.FnApiRunnerTestWithGrpcAndMultiWorkers
https://github.com/apache/beam/issues/20976 
apache_beam.runners.portability.flink_runner_test.FlinkRunnerTestOptimized.test_flink_metrics
 is flaky
https://github.com/apache/beam/issues/20108 Python direct runner doesn't emit 
empty pane when it should
https://github.com/apache/beam/issues/19814 Flink streaming flakes in 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInStartBundleStateful and 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElementStateful
https://github.com/apache/beam/issues/19465 Explore possibilities to lower 
in-use IP address quota footprint.


P1 Issues with no update in the