[beam] branch master updated: Add java Bigquery IO known issue to beam 2.40 release blogpost (#22611)

[jo...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

johncasey pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/beam.git


The following commit(s) were added to refs/heads/master by this push:
     new 9bf7942f32c Add java Bigquery IO known issue to beam 2.40 release blogpost (#22611)
9bf7942f32c is described below

commit 9bf7942f32c3c9cc5290b94f92318c96c85da086
Author: johnjcasey <95...@users.noreply.github.com>
AuthorDate: Fri Sep 2 14:00:10 2022 -0400

    Add java Bigquery IO known issue to beam 2.40 release blogpost (#22611)
    
    * Add java Bigquery IO known issue
    
    * add note about drainability
    
    * Add update about fix version
---
 website/www/site/content/en/blog/beam-2.40.0.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/website/www/site/content/en/blog/beam-2.40.0.md b/website/www/site/content/en/blog/beam-2.40.0.md
index 989c01fee1d..f9a60b7e8af 100644
--- a/website/www/site/content/en/blog/beam-2.40.0.md
+++ b/website/www/site/content/en/blog/beam-2.40.0.md
@@ -65,6 +65,10 @@ For more information on changes in 2.40.0 check out the [detailed release notes]
   constructed with some
   [built-ins](https://docs.python.org/3/library/functions.html), like ``sum``
   and ``len`` ([#22091](https://github.com/apache/beam/issues/22091)).
+* Java's ``BigQueryIO.Write`` can have an exception where it attempts to output a timestamp beyond the max timestamp range
+    ``Cannot output with timestamp 294247-01-10T04:00:54.776Z. Output timestamps must be no earlier than the timestamp of the current input or timer (294247-01-10T04:00:54.776Z) minus the allowed skew (0 milliseconds) and no later than 294247-01-10T04:00:54.775Z. See the DoFn#getAllowedTimestampSkew() Javadoc for details on changing the allowed skew.``
+    This happens when a sink is idle, causing the idle timeout to trigger, or when a specific table is idle long enough when using dynamic destinations.
+    When this happens, the job is no longer able to be drained. This has been fixed for the 2.41 release.
 
 ## List of Contributors