Optimize Simplified Chinese translation

Optimize simplified Chinese translation and Add Language Select

Please, take a look - the resources are stored twice. Can you fix it? Or may I do it manually later?
Thanks.

BTW: What do you think about issue with lowercase language code as a suffix of file? Some guy mentioned that had some issue on Linux with it?
Thx.

OK, thank you!
I will check it and merge it.


ArrayList vs List

Description
In line 16
ImList newList = new ImList(this.elems)
But the constructor takes in a list
ImList(List<T> list) {
  this.elems = new ArrayList<T> (list);
}

Why is this not a problem?
Topic:
Screenshots

Hint: ArrayList implements List interface

If I am not wrong, List is an interface, and you cannot instantiate an interface. That's why you need some implementation, in this case, prof uses ArrayList (under List interface), which is basically a List implemented over an array. Can also check https://www.geeksforgeeks.org/difference-between-list-and-arraylist-in-java/
So from line 16, it will invoke the constructor at line 11, and because of what I mentioned above, there will be no error occurred as ArrayList implements the List interface.
Really sorry if there's a misconception, but if anyone would like to correct me or add something on, please go ahead!

Refer to Lecture #1 Slide #15.  The code snippet shows that ArrayList (or LinkedList) is a List.  More shall be reviewed in Lecture #5. 😃


Add v1 conversion for pipelinerunref.bundle

Changes

This commit adds support for PipelineRef.Bundle when converting between
v1beta1 and v1 versions of PipelineRef. This allows us to release v1
PipelineRuns in a backwards compatible way by ensuring that v1beta1
PipelineRuns with Bundle converted to v1 pipelineRuns.
part of #4987
/kind misc
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[n/a] Has Docs included if any changes are user facing
[n] Has Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

/kind misc

/assign @lbernick

/retest

/retest

/lgtm


[libpng] Remove -DPNG_PREFIX=a option when apng feature enabled

This option has the effect of manipulating the ELF version and symbol scripts applied to the shared library to define symbols like "apng_read_end@@PNG_16_0". When using a fully shared setup and linking other system libraries (for example, Qt6) in an application, this causes system libraries that were linked against the system libpng.so to fail to find libpng symbols. Because they have a prefix of "a".
This should have been removed in the merge from two separate ports into one port with a feature in
ff6a725392fcffa647880293e4c0a1352f0d3473

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

An example of the failure when using VCPKG_LIBRARY_LINKAGE of 'dynamic' is like so:
/home/andrew/ladybird-org/ladybird-browser/Build/ladybird/libexec/RequestServer: symbol lookup error: /lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: png_read_end, version PNG16_0

Because the lib as created by vcpkg does not export that symbol (png_read_end@@PNG16_0) but instead a host of versioned symbols with the name "apng_*"

/home/andrew/ladybird-org/ladybird-browser/Build/ladybird/libexec/RequestServer: symbol lookup error: /lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: png_read_end, version PNG16_0

Sidenote: satisfying a system lib's dependencies with vcpkg libs could be error-prone. A cairo port exists.

Sidenote: satisfying a system lib's dependencies with vcpkg libs could be error-prone. A cairo port exists.

Fair enough, but adding qt6 libraries and its dependencies to our vcpkg config at this point doesn't make much sense for our project. we don't need any customization to qt, and building it from source without some kind of shared binary cache for contributors to use sounds like a massive hassle and waste of compute.

/azp run


fix: fix doc link

Resolves #1429

I think there's an issue somewhere else where we generate the docs as I had to add that v the other day to fix links from the CLI output

I think there's an issue somewhere else where we generate the docs as I had to add that v the other day to fix links from the CLI output

This is the CLI links. Think the issue being fixed was the latest version wasn't it?

It was the v but i have no idea how that's possible :S https://github.com/aquasecurity/tfsec/issues/1395

It was the v but i have no idea how that's possible :S https://github.com/aquasecurity/tfsec/issues/1395

Checked the goreleaser docs, pre release versions have the v stripped on pre release docs.
We use {{. Version}} in the golreaser manifest so I think we should play about with using {{.Tag}} longer term
But short term this fixes the issue

@owenrumney Cool, time for 1.0.1 then - was hoping 1.0.0 would last a while :D

I think this change broke it again with the same effect as reported in #1395
TFsec output:
          ID aws-s3-specify-public-access-block
      Impact Public access policies may be applied to sensitive data buckets
  Resolution Define a aws_s3_bucket_public_access_block for the given bucket to control public access policies

  More Information
  - https://aquasecurity.github.io/tfsec/1.0.1/checks/aws/s3/specify-public-access-block/
  - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_public_access_block#bucket

The URL above returns 404.
The published URL has v in the version:
https://aquasecurity.github.io/tfsec/v1.0.1/checks/aws/s3/specify-public-access-block/

Environment:
$ uname -sm
Linux x86_64

$ tfsec --version
1.0.1

this is fixed now - thanks @sergei-ivanov


add frontend check in test deployment to only allow running on testnet

doesn't seem to work, maybe @kenodressel you can check


fix html entities like & in emails

Coverage increased (+0.005%) to 74.916% when pulling 228af134e9345f6153d5cea5c441a3c55325eb9f on fixHTMLEntitiesInEmail into 35c0520de1d56350d8eff5248582d97b02977750 on master.


Removing repeat lines

Removing lines that are just repeats separated by a comma, since they don't do anything

@dav3r, I added in DOD.  OGE was already present under the name Office of Government Ethics.  (That's the name used in current-federal as well.)


Change to Asyncio API request

Add batching to break the request in smaller pieces.
Added function to make asyncio make_api_function.
Wrote Asyncio function to get historical data.

Nice work @MeenaBana! The "New_functions_test" notebook - can that be deleted?


Cleanup rebar3 / mix Test Config

Part of #221

Pull Request Test Coverage Report for Build 37

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.091%

Totals

Change from base Build 47:
0.0%

Covered Lines:
452

Relevant Lines:
519

💛  - Coveralls


Xmc4xxx interrupt controller

Do not merge.
This PR requires a HAL Infineon update:
https://github.com/zephyrproject-rtos/hal_infineon/pull/3
The gpio support is a separate PR:
https://github.com/zephyrproject-rtos/zephyr/pull/47905
This main aim of this PR is to review interrupt controller driver.
In Infineon XMC4XXX SoCs, gpio interrupts are triggered via an
Event Request Unit (ERU) module. A subset of the gpios are
connected to the ERU. The ERU monitors edge triggers and creates
a SR.
The interrupt controller driver configures the ERU for a target port/pin combination
for rising/falling edge events. Note that the ERU module does
not generate SR based on the gpio level. Internally the ERU
tracks the status of an event. The status is set on a positive
edge and unset on a negative edge (or vice-versa depending on
the configuration). The value of the status is used to implement
a level triggered interrupt; The ISR checks the status flag and
calls the callback function if the status is set.
The ERU configurations for supported port/pin combinations are
stored in a devicetree file dts/arm/infineon/xmc4xxx_x_x-intc.dtsi.
The configurations are stored in the opaque array
uint16 port_line_mapping[].

Can I suggest keeping this PR in draft state, since it's dependent on multiple PRs being merged first?

This PR probably shouldn't be assigned to the GPIO maintainer. However, the interrupt-controller driver area is lacking a maintainer currently. Any suggestions?

ping

Needs rebase

Needs rebase

Thanks, I've rebased. I also added a fix for a special case where the gpio level was set active before the interrupt was configured.

This PR probably shouldn't be assigned to the GPIO maintainer. However, the interrupt-controller driver area is lacking a maintainer currently. @galak - any suggestions?

No suggestion.

This PR probably shouldn't be assigned to the GPIO maintainer. However, the interrupt-controller driver area is lacking a maintainer currently. @galak - any suggestions?

No suggestion.

@carlescufi, @cfriedt, thank you for reviewing


furnace: missing zenity/kdialog dependency

Describe the bug
Can't save in furnace if zenity or kdialog is not installed.
Steps To Reproduce
Steps to reproduce the behavior:

Run furnace without zenity or kdialog installed

Expected behavior
Zenity or kdialog should be given to the furnace, based on which DE is installed (in case of WMs, the smallest thing)
Screenshots

Additional context
...
Notify maintainers
@OPNA2608
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.41-rt37, NixOS, 24.11 (Vicuna), 24.11.20240728.52ec9ac`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - channels(user): `""`
 - nixpkgs: `/nix/store/bcghcr9qwqmanpds017w75mcqda4fgab-source`

Add a :+1: reaction to issues you find important.

Can't save in furnace if zenity or kdialog is not installed.

You can use the built-in file dialogue, the error tells you how to switch to it.

Zenity or kdialog should be given to the furnace, based on which DE is installed (in case of WMs, the smallest thing)

This is just not possible unless we make separate furnace packages for wrapping with zenity or wrapping with kdialog. And if we do that, then you would need to check every package you install that uses a mechanism like this to make sure you've installed the variant matching your environment.
I can ask on Matrix, but I think usually the package maintainer just picks one of the two, i.e. zenity, and makes that the only option. Our DEs don't seem to install zenity/kdialog either? :confused:


SOS！I need help

Hello,I have two questions.

how can i change 127,0.0.1:4200 to my ip:4200
how can I change the 5Mb max size restriction.

Port 4200 is only for UI developers. If you just want to use CompreFace, follow our Getting Started guide:
https://github.com/exadel-inc/CompreFace/blob/master/README.md#getting-started-with-compreface
Here is the issue related to it:
How can I remove the 5MB upload limit #680

Sorry. Firstly, I change the application.yml with 10Mb value to 100Mb, then use docker-compose up -d and sh start.h to build Compreface. But it still looks like have a 5Mb limit when I use the python-sdk.
Is there something wrong with my operation? I'm sorry to bother you

to build CompreFace you need:

Run docker-compose build
Run docker-compose up
This is it. CompreFace will be on 8000 port.
4200 port is needed only for development, you shouldn't use it for production.

To fix second issue:
    1. Edit file nginx.conf: Set client_max_body_size 50M;
    2. Edit file docker-compose.yml, add volumes to compreface-core:
            volumes:
                - nginx_conf_volume:/etc/nginx/conf.d
    nginx_conf_volume should be also decrared on top of file:
            volumes:
                - nginx_conf_volume:
    3. Run command: docker-compose up
    4. Copy nginx.conf: docker cp /path/to/nginx.conf compreface-ui:/etc/nginx/conf.d
    5. Restart compose.


rro.rb sha256 mismatch

The sha256 sum for RRO-3.2.2-OSX.pkg in line 3 of rro.rb should be d7d096f5e258a6b1945235aefcdf9c52b3e63daaa515d39305a864f6a3a7b640.

Care to submit a PR? It isn’t a complex fix, and we’re here to help.

Fixed in #15119


Regular server errors for code.google.com

DEBUG    pypidb._scm_url_cleaner:__init__.py:157 Calling pypidb._scm_url_cleaner.SCMURLCleaner.get_root(self = <pypidb._scm_url_cleaner.SCMURLCleaner object at 0x7fb7ea9671f0>, url = 'http://code.google.com/p/modwsgi/wiki/VirtualEnvironments')
DEBUG    pypidb._scm_url_cleaner:_scm_url_cleaner.py:291 google code http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
DEBUG    pypidb._scm_url_cleaner:_scm_url_cleaner.py:309 google code p modwsgi/wiki/VirtualEnvironments
DEBUG    pypidb._adapters:_adapters.py:57 domain block of https://code.google.com/p/modwsgi skipped
DEBUG    pypidb._adapters:_adapters.py:33 IPblock of https://code.google.com/p/modwsgi skipped
DEBUG    https_everywhere.adapter:adapter.py:86 No implementation for get_redirect('https://code.google.com/p/modwsgi')
DEBUG    https_everywhere.adapter:adapter.py:117 no redirection of https://code.google.com/p/modwsgi occurred
DEBUG    cachecontrol.controller:controller.py:126 Looking up "https://code.google.com/p/modwsgi" in the cache
DEBUG    cachecontrol.controller:controller.py:141 No cache entry available
DEBUG    urllib3.connectionpool:connectionpool.py:955 Starting new HTTPS connection (1): code.google.com:443
DEBUG    urllib3.connectionpool:connectionpool.py:428 https://code.google.com:443 "GET /p/modwsgi HTTP/1.1" 500 290
DEBUG    cachecontrol.controller:controller.py:257 Status code 500 not in (200, 203, 300, 301, 302, 401, 404)
DEBUG    pypidb._scm_url_cleaner:__init__.py:198 Exception HTTPError occurred in pypidb._scm_url_cleaner.SCMURLCleaner.get_root, "500 Server Error: Internal Server Error for url: https://code.google.com/p/modwsgi"

Also
DEBUG    pypidb._scm_url_cleaner:__init__.py:198 Exception HTTPError occurred in pypidb._scm_url_cleaner.SCMURLCleaner.get_root, "502 Server Error: Bad Gateway for url: https://code.google.com/p/mosh-scheme"

There were both while looking for msgpack-python.
Two approaches which come to mind

Better queuing ordering to delay code.google.com until other better hosts are attempted
Temporarily ignore 5xx errors, and re-queue the failed URL, so that other URLs can be attempted.

Same problem with mpmath, which queues 'http://code.google.com/p/mpmath/' before 'https://github.com/fredrik-johansson/mpmath'

This needs a bit more time to fix properly, and there are lower fruit to speed up resolution of Python 3 packages.

https://github.com/jayvdb/pypidb/issues/94 is a good example, as the GitHub repo is found very early, and yet it can timeout looking for clearly unrelated pydoc
DEBUG    pypidb._scm_url_cleaner:__init__.py:157 Calling pypidb._scm_url_cleaner.SCMURLCleaner.get_root(self = <pypidb._scm_url_cleaner.SCMURLCleaner object at 0x7fac1ed22d90>, url = 'http://code.google.com/p/pydot/')
DEBUG    pypidb._scm_url_cleaner:_scm_url_cleaner.py:303 google code http://code.google.com/p/pydot/
DEBUG    pypidb._scm_url_cleaner:_scm_url_cleaner.py:321 google code p pydot/
DEBUG    pypidb._scm_url_cleaner:__init__.py:198 Exception HTTPError occurred in pypidb._scm_url_cleaner.SCMURLCleaner.get_root, "500 Server Error: HTTPS Everywhere for url: https://code.google.com/p/pydot"


[MISC] Rewrite and update html build instructions

closes #1030
This is changing the order of instructions:

first clone
then navigate to the spec
then install python via requirements.txt

that's important because we have the schema package, which is local -- so navigating to the local dir of the spec ensures success.
Furthermore I recommend using an isolated python environment -- that way we can do without the "special instructions" in case somebody doesn't want numpy (in an isolated env it doesn't really matter if they have numpy or not).

I think this issue fits here. When I modified README description in src/schema/objects/top_level_files.yaml neither mkdocs serve nor mkdocs build --clean --strict --verbose would build the modified version. Executing pip3 install --upgrade tools/schemacode/ helped. I find it weird.

That's a bit weird indeed - I clarified with Taylor (who is the expert on everything schema related) and he couldn't replicate your issue. Furthermore, the CI pretty much runs the same code as you, and there the changes also appeared in the build output.
https://github.com/bids-standard/bids-specification/blob/88a9730d566b5a82ee6ab89546220914e3f303a0/.circleci/config.yml#L6-L24
Perhaps that's some idiosyncratic issue on your system/setup OR you maybe did a mistake somewhere? Anyhow, if you have a concrete suggestion what to improve, please let me know :-)

I tried it again carefully from scratch.

Create venv, build and serve. Everything works as expected.

python3 -m venv mkdocs-env
source mkdocs-env/bin/activate
pip3 install --upgrade pip
pip3 install --requirement requirements.txt
mkdocs build --clean --strict --verbose
mkdocs serve

Modify a file, build, serve and see the changes. No changes generated.

vim src/schema/objects/top_level_files.yaml
...
mkdocs build --clean --strict --verbose
mkdocs serve

Removing site directory and building again doesn't help.

My versions of the Python packages:
Package                           Version
--------------------------------- -----------------
click                             8.0.4
ghp-import                        2.0.2
gitdb                             4.0.9
GitPython                         3.1.27
importlib-metadata                4.11.3
Jinja2                            3.0.3
Markdown                          3.3.6
MarkupSafe                        2.1.1
mergedeep                         1.3.4
mkdocs                            1.2.3
mkdocs-branchcustomization-plugin 0.1.3
mkdocs-macros-plugin              0.6.4
mkdocs-material                   8.2.6
mkdocs-material-extensions        1.0.3
numpy                             1.22.3
packaging                         21.3
pandas                            1.4.1
pip                               22.0.4
pkg_resources                     0.0.0
Pygments                          2.11.2
pymdown-extensions                9.3
pyparsing                         3.0.7
python-dateutil                   2.8.2
pytz                              2022.1
PyYAML                            6.0
pyyaml_env_tag                    0.1
schemacode                        1.7.0+21.g559551f
setuptools                        44.1.1
six                               1.16.0
smmap                             5.0.0
tabulate                          0.8.9
termcolor                         1.1.0
watchdog                          2.1.6
zipp                              3.7.0

I couldn't find any related issue in https://github.com/fralau/mkdocs_macros_plugin/

I think I've found the problem. The tools/schemacode/ package is installed with the data directory, where a copy of the schema resides. In my case mkdocs-env/lib/python3.9/site-packages/schemacode/data/schema/objects/top_level_files.yaml has the content from the moment of installing tools/schemacode/. My guess is, that schemacode's version of the schema content is used whenever mkdocs build is executed.
I changed the content of mkdocs-env/lib/python3.9/site-packages/schemacode/data/schema/objects/top_level_files.yaml file and changes are reflected after mkdocs build.

You can also use pip install -e to install a package in editable mode.

Thanks @mateuszpawlik for investigating, that makes sense ... I hadn't thought of that. I took Chris' solution and added it as a commit to the contributor instructions.

Failures are due to Jinja2 3.1 release 30 minutes ago:

https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-0
https://pypi.org/project/Jinja2/#history


haskellPackages.postgrest broken

Steps To Reproduce
$ nix-build -A haskellPackages.postgrest

Additional context
The package refuses to evaluate because configurator-pg-0.2.7 is marked as broken; after fixing that a number of other issues occur.
I managed to get it to work locally by applying the following nixpkgs overlay (mostly changing package versions) - but I don't know how to make a proper PR for the Haskell package set that fixes all these issues in the correct way. Maybe some kind maintainer can help me out?
I have also tried with the latest haskell-updates branch but that does not resolve the issues.
(final: prev: {
  haskellPackages = prev.haskellPackages.override {
    overrides = let
      inherit (pkgs.haskell.lib.compose)
        doJailbreak
        markUnbroken
        overrideSrc
        overrideCabal
        addBuildDepends
      ;
    in
      self: super: {
        configurator-pg = pkgs.lib.pipe super.configurator-pg [
          markUnbroken
          doJailbreak
        ];
        fuzzyset = pkgs.lib.pipe super.fuzzyset [
          markUnbroken
          (overrideCabal (drv: {
            version = "0.2.4";
            sha256 = "sha256-tsOPShYkKxCccIwKj1aL4rURgXWN4N8HJyV5Jn5pRmY=";
            revision = "0";
            editedCabalFile = "sha256-8bbei/Myd79iVSB1QdZQKPHx6pOvVUG2VMhrVnSZVIU=";
          }))
          (addBuildDepends [
            self.data-default
          ])
        ];
        hasql-pool = pkgs.lib.pipe super.hasql-pool [
          (overrideCabal (drv: {
            version = "0.10";
            sha256 = "sha256-EeyKo3NPIpBLv6e7DVQYMus3soGtMC/IzKVg6qBWBZY=";
            revision = "0";
            editedCabalFile = "sha256-kSGXoyisuFUF+Yu5cA1h82a4dlnKRRJsXC1jZoe4AcM=";
          }))
        ];
        postgrest = pkgs.lib.pipe super.postgrest [
          (overrideSrc {
            version = "11.2.2";
            src = pkgs.fetchFromGitHub {
              owner = "PostgREST";
              repo = "postgrest";
              rev = "v11.2.2";
              hash = "sha256-6Nv0NSAiNUSg2T/cmWs7zGSInLSmF0WDA3E/KxlA7O8=";
            };
          })
          (addBuildDepends [
            self.extra self.fuzzyset self.cache self.timeit
          ])
        ];
      };
  };
})

Notify maintainers
@cdepillabout @sternenseemann
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.2, NixOS, 24.05 (Uakari), 24.05.20231123.79245fc`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(frijters): `""`
 - channels(root): `""`
 - nixpkgs: `/etc/nixpkgs`

Add a :+1: reaction to issues you find important.

I'm currently using your overlay as a fix, so thank you. configurator-pg had this PR merged recently that should fix it not building because the megaparsec version is too high. So I guess what we need is a PR against nixpkgs to bump the postgrest version to 11.2.2, but what's going on with fuzzyset and hasql-pool?

fuzzyset is marked as broken in nixpkgs (even though it doesn't seem to be), but if I only markUnbroken I get a bunch of build errors in postgrest related to functions that are not (no longer) exported, so I downgraded it from 0.3.1 -> 0.2.4 which still has these functions. I tried to add it to the list of packages that retain an old version in nixpkgs but the autogenerated files don't seem to incorporate it, so I'm probably doing something wrong - hence my appeal to the Haskell team.
hasql-pool has also seen a relevant breaking API change: the signature of SQL.acquire seems to have changed. In this case a newer version was required, so I assume this will be automagically fixed in nixpkgs when new snapshots are used. And hopefully this will include a version bump of postgrest itself as well.

Note that I'm not overly familiar with any of these packages: I just use postgrest in a demo similar to https://nixos.wiki/wiki/NixOS_Testing_library - which makes me want to get this fixed since new people might try this and run into these issues with the current nixpkgs. I now also saw that https://nix.dev/tutorials/nixos/integration-testing-using-virtual-machines is now using a simpler example, so for my use case I might just switch to that as well.

@SFrijters If you start a PR which displays your PR we can iterate on it. If this is only about pinning a few packages to the right versions, this should be doable. Also the interest in this issue seems so big, that it seems worth it.
I don’t know, however, if we can get the fix in for the current haskell-updates generation. Depends on when I have the time to finish it up.

Fixes have hit haskell-updates; I'll close this issue when they hit master.

Fixed by https://github.com/NixOS/nixpkgs/pull/275614 ; thanks to @maralorn and @rvl for their help!


Page with At sign (@) at the beginning of the file name ignored by routes

Describe the bug
Hello everyone. In my project I want:
https://example.com/123 <- to be an article detail page
https://example.com/@123 <- to be a user detail page
And If i create two files:

[id].svelte
@[id].svelte

it does not work. It always goes with [id].svelte
However, this works as expected:

[id].svelte
u[id].svelte

Reproduction
1) Create two files:

[id].svelte
@[id].svelte

2) [id].svelte:
<script context="module">
    export const load = async ({page}) => {
        console.log(page.params.id)
    };
</script>

3) Navigate browser to http://localhost:3000/@1
4) See output of console.log(page.params.id)
It'll be @1 instead of 1
System Info
System:
  OS: macOS 11.4
  CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
  Memory: 253.82 MB / 16.00 GB
  Shell: 3.2.57 - /bin/bash
Binaries:
  Node: 16.6.2 - /usr/local/bin/node
  Yarn: 1.22.11 - /usr/local/bin/yarn
  npm: 7.20.3 - /usr/local/bin/npm
Browsers:
  Chrome: 93.0.4577.82
  Safari: 14.1.1
npmPackages:
  svelte: ^3.34.0 => 3.42.6

Severity
annoyance

Note: The fix might be related to #2401, but looks like it's a different issue.

Looks like a duplicate of that issue to me. I just merged the fix


Color schemes from Iterm2-color-schemes and Tomorrow Themes

Added color schemes Iterm2-color-schemes and Tomorrow Theme.
This includes a script to convert .itermcolors to .pp.


Fixes in DTPHandler.use_sendfile and Epoll.poll

Hi!
Thanks for your awesome work on pyftpdlib!
Here are two fixes, quite important in some cases, gathered from our production experience.
1. DTPHandler.use_sendfile
In one rare case in our environment pyftpdlib went into an infinite traceback printing loop.
May be a rare thing, I suspect it was mainly because of our environment: filesystem is a NAS-backed NFS, so things happen. Basically, it went something like this from my understanding:

event loop tries to close a connection
it then tries to close opened file, but fails to do so
during error handling and logging, calls get_repr_info() -> use_sendfile() -> fileno()
fileno() fails and event is not processed
event tries to get processed the next tick of event loop, with similar result

This was happening many times per second. I'm going to attach a relevant traceback.
2. Epoll.poll
In some cases I observed infinite hanging of a connection thread. Basically, in some cases Epoll.poll() gets called with timeout = 0, but it causes it to call self._poller.poll(-1). At the same time there are no more events on the socket. The timeout idler should have triggered, but the thread (we use threaded server) is stuck on poll(-1).
I guess zero timeout comes from _Scheduler.poll when the top-most task is overdue:
return max(0, self._tasks[0].timeout - now)

Here is a pystack snapshot from our production env:
Traceback for thread 30 (python) [] (most recent call last):
    (Python) File "/usr/local/lib/python3.10/threading.py", line 973, in _bootstrap
        self._bootstrap_inner()
      Arguments:
        self: <Thread at 0x7f0c68e16440>
    (Python) File "/usr/local/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
        self.run()
      Arguments:
        self: <Thread at 0x7f0c68e16440>
    (Python) File "/usr/local/lib/python3.10/threading.py", line 953, in run
        self._target(*self._args, **self._kwargs)
      Arguments:
        self: <Thread at 0x7f0c68e16440>
    (Python) File "/usr/src/app/.venv/lib/python3.10/site-packages/pyftpdlib/servers.py", line 402, in _loop
        poll(timeout=soonest_timeout)
      Arguments:
        handler: <OVFXHandler at 0x7f0c6a23d5a0>
        self: <ThreadedFTPServer at 0x7f0c6a312170>
      Locals:
        poll_timeout: 1
        soonest_timeout: 0
        sched_poll: <method at 0x7f0c67f27500>
        poll: <method at 0x7f0c67f25b40>
        ioloop: <Epoll at 0x7f0c6961bd30>
    (Python) File "/usr/src/app/.venv/lib/python3.10/site-packages/pyftpdlib/ioloop.py", line 521, in poll
        events = self._poller.poll(timeout or -1)  # -1 waits indefinitely
      Arguments:
        timeout: 0
        self: <Epoll at 0x7f0c6961bd30>

The mentioned traceback:
loki-logs-export.txt


Editing files in correct directory

In the python exercises we tell the students to write a file and then read it with python.
Unfortunately we don't tell them to write that file in the same directory as where the notebook is, so it was causing a little bit of confusion. We might want to be a bit more explicit in our instructions here.

This is no longer part of the exercises.


adds port to sqlcmd calls, plus tests

While the entire connection string is passed directly to SqlPackage, because sqlcmd requires individual parameters (glare) we were dropping the port number from script execution and more importantly, connectivity testing.
This most prominent issue we saw was with SQL MI public endpoint connectivity, which uses 3342.
If no port is specified in the connection string, the default (1433) is used.
fyi @miljann995
I had an additional test of sqlcmd variables being picked up in sqlpackage calls in my local, so that's along for the ride.
secret value being used for public endpoint:

error on<EMAIL_ADDRESS>with debug logging enabled, shows it used 1433

same workflow with sql-action@drskwier/fix-server-port, connects successfully

merging in, but will consider how to smooth over the firewall rule component for SQLMI in the future


Listen to more plots properties on selected and click events

Description
I just stumbled across the dash documentation regarding selection here. Here they have a very useful features which allows to also capture the custom_data , that is data that we add to the points plotted. It can be used so that the developer add index of rows in the custom_data (very easy with plotly express hover_data argument) and then the developer of the dash op can link the point selected with a row of its dataframe to apply further processing.
This is not the case in Taipy where you only capture the position lat lon or the x y coordinate of the plot for a click event, and the index of the traces selected for the selected property.
Would it be possible for taipy to have this dash feature ? i.e. listen to the same property as dash, or simply get access to the custom_data of points clicked/selected?
A use case for that is the one I describe here :
"Just to be clear, my end goal is to be able to click on a point on the map, and get the index of the element of dataframe corresponding to the point I clicked."
Related to issue #1786
Acceptance Criteria

[ ] Ensure new code is unit tested, and check code coverage is at least 90%.
[ ] Create related issue in taipy-doc for documentation and Release Notes.
[ ] Check if a new demo could be provided based on this, or if legacy demos could be benefit from it.
[ ] Ensure any change is well documented.

Code of Conduct

[X] I have checked the existing issues.
[ ] I am willing to work on this issue (optional)

kindly assign me the issue @ShootingStarD . i would like to contribute

kindly assign me the issue @ShootingStarD . i would like to contribute

I am not part of the Taipy team so I cannot assign it to you, moreover since it supposes major changes in taipy callback return structures so it has to be first discussed with Taipy maintainers


[Gally]: master <- dev

Automatically created by Git-Ally

:tada: This PR is included in version 1.10.125 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


DCGAN training gone wrong

Hi,
When running the first notebook, as-is, from chapter 4, I am getting very odd results.
During training, I could notice very huge swings of accuracy/loss of the generator/discriminator, and after about 240 epochs all hell breaks loose, with the discriminator apparently starting to predict all images as fake ones (fake discrimator acc remains at 1, while real discrimator acc remains at 0).
Trying to wrap my head around what may be happening here. Given that I have not altered the code, the only difference would be the seeds for random noise used as input to the generator. But I doubt that this could cause such wide differences compared to the results presented in the chapter (the graphs presented in the chapter are quite smooth compared to my run).
It doesn't seem like its a case of the discriminator overpowering the generator, even though it seems to be the case on some prior epochs where the discrimator acc is peaking at 1 (or maybe it is a case of discriminator overpower, given that it predicts all images produced by the generator as fake ones). I don't really understand why the discriminator would suddenly drop to being "perfect" in term of accuracy (while it had about the same acc for real/fake during training) to stay at a perfect average after epoch 240 (nor while it swinged so widely during training or plateaued at 1 for some epochs, then suddenly dropping).
Could there be a "bug" that slipped into the code ?
Do you have any intuition as to what may have gone wrong ?
And more generally, as a novice practitioner, what should be the thought process here for troubleshooting such a training gone bad ?
Thanks !

I haven't run the code, but my guess is that the noise is wrong.
in train_step
real_labels = tf.ones_like(real_predictions)
real_noisy_labels = real_labels + 0.1 * tf.random.uniform(
               tf.shape(real_predictions)) # it goes to [1.0, 1.1]
fake_labels = tf.zeros_like(fake_predictions)
fake_noisy_labels = fake_labels - 0.1 * tf.random.uniform(
                tf.shape(fake_predictions)) # it goes to [-0.1, 0]

i think it should
real_labels = tf.ones_like(real_predictions)
real_noisy_labels = real_labels - 0.1 * tf.random.uniform(
               tf.shape(real_predictions)) # it goes to [0.9, 1.0]
fake_labels = tf.zeros_like(fake_predictions)
fake_noisy_labels = fake_labels + 0.1 * tf.random.uniform(
                tf.shape(fake_predictions)) # it goes to [0., 0.1]

if i was wrong, correct me


Allow users to input fractional feerate

I can input 6 sats or 7 sats but not 6.5 (the replaced tx fee rate is much lower than 6 sats/vB).
It’s especially useful for low feerate txs, if a tx is at 1 sats/vB, currently there’s no choice but to double the fee paid.

Thanks for reporting this issue.
Allowing fractional feerates (for both new spends and RBFs) is certainly feasible and we will consider this for a future release.


test: add units tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@4980182). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             main     #20   +/-   ##
======================================
  Coverage        ?   5.39%
======================================
  Files           ?      21
  Lines           ?     556
  Branches        ?       0
======================================
  Hits            ?      30
  Misses          ?     526
  Partials        ?       0

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4980182...ef998df. Read the comment docs.


May I ask the training time?

Hi, may I ask how many images do you use and how long will it cost for finish the training?

for enstext, I only use the 2749 training samples and takes about 1-2 days
for training on a single 2080ti GPU
kylechang523 @.***> 于2023年3月31日周五 07:04写道：

Hi, may I ask how many images do you use and how long will it cost for
finish the training?
—
Reply to this email directly, view it on GitHub
https://github.com/lcy0604/EraseNet/issues/15, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ7RD3REAOCW4KNMU5GM633W6YGPBANCNFSM6AAAAAAWN5NRPQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Execution Reverted

One partner is having this issue consistently in the last few days while using the public RPC.
{
    "code": -32603,
    "message":
    "[ethjs-query] while formatting outputs from RPC '{\"value\":{\"code\":-32603,\"data\":{\"code\":3,\"message\":\"execution reverted\",\"data\":\"0x\"}}}'"
}

@mfornet Are there any additional info? Maybe script that I can use to reproduce this?

It happens from time to time on saving actions on https://moonflowerfarmers.com/.

To replicate use:
Create a farm here:
https://moonflowerfarmers.com/
ABI: Uploading FarmV5.txt…
Hosted at: 0xDE707357D10D86aE21373b290eAbBA07360896F6
call the sync public function with this payload:
[
{
"action": 0,
"fruit": "1",
"landIndex": 1,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 2,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 3,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 1,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 2,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 3,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 1,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 2,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 3,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 0,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 4,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 0,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 2,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 4,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 3,
"createdAt":<PHONE_NUMBER>
},
{
"action": 1,
"fruit": "0",
"landIndex": 1,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 0,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 2,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 3,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 4,
"createdAt":<PHONE_NUMBER>
},
{
"action": 0,
"fruit": "1",
"landIndex": 1,
"createdAt":<PHONE_NUMBER>
}
]

Having the same issue with one of our functions on testnet.  To reproduce:

Contract
In the claim() function fill in these values:

To: 0x237f6EC93A1E68819b24361aBC1e8cf5cA8d9bce
Amount:<PHONE_NUMBER>00000000000
Proof: 0xcd537fb58a8b1f066d539bd51ef725bfab2cb0487cbe5f430d1394f3e4a00962

Claim and sign the TX with metamask.  Which will return this error:

[ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":3,"message":"execution reverted","data":"0x8a585be2"}}}'

@mfornet Any updates here :)

It seems to me that there is a problem with the contract, and it is being reverted due to some issue inside the logic of the contract. I kind of confirmed this by looking into @chad-mcdonald provided contract, you can see how most of the transactions are failures, and that is not related to the RPC.
However, the RPC should be able to return back a better error message which could be parsed by off-chain tools. This was addressed at https://github.com/aurora-is-near/aurora-relayer/pull/97, but it looks like it wasn't completely addressed at that point. cc @spilin

Hey, @mfornet @end0cr1ne . We will investigate it this week. As to returning proper errors, as of now it's not all of the messages can be returned.

The only reason I assumed that it was engine related is that these started last week randomly without any change from my end :(

Hey @spilin did you get a chance to look into this. My app's significantly affected 😔

The only reason I assumed that it was engine related is that these started last week randomly without any change from my end :(

@end0cr1ne this suddenly started happening on testnet or mainnet? There have been no changes to the Engine on mainnet since Feb 23 (1 month ago).

This repository is deprecated. If issue still persists, please reopen it on a new repository of Aurora Relayer v2.


RPP Tensor Normalize ND on HOST and HIP

Adds support for Tensor Normalize ND on HOST and HIP
Adds relevant Unit/Perf/QA tests

@r-abishek -- needs conflicts resolved

@r-abishek needs merge conflicts resolved

@LakshmiKumar23 : Can you please review this PR

@r-abishek -- merge conflicts resolved to merge

@r-abishek -- some more conflicts

@kiritigowda Merge conflicts fixed.
All Audio HOST passing:

All Normalize ND HOST passing:


How can I get post information?

I see you have been able to get posts using this: https://github.com/szdc/tiktok-api#getpostid
I'm trying to decipher how you do this, but I can't seem to figure it out.
I'll paste my code below. I've also tried putting aweme_id directly in the options instead of under params but it didn't work. How are you making this request?
function getTikTokStats() {
  try {
    var url = "https://api2.musical.ly/aweme/v1/aweme/detail/";
    var options = {
      "followRedirects" : true,
      "muteHttpExceptions": true,
      "params": {
        "aweme_id": "6829058293818821893"
      }
    };
    var result = UrlFetchApp.fetch(url, options).getContentText();
    var json = JSON.parse(result);
  } catch(e) {
    Logger.log( e);
    return "ERROR";
  }
}

Closing as this project is no longer maintained.


Feature/automatically assign user to tenant

@Naoray thank you for this. Can you clarify what this is doing?
Multitenancy::TENANT_SET_HEADER

Because for the check at https://github.com/romegadigital/Multitenancy/pull/28/files#diff-1ba8f7072124cbd1d56f415e9c541358R17 to prevent the tenant assignment when a user is created from console or otherwise


WhiteNoise middleware added in the wrong place

From WhiteNoise's documentation, the middleware should be added after the security one:

Edit your settings.py file and add WhiteNoise to the MIDDLEWARE_CLASSES list, above all other middleware apart from Django’s SecurityMiddleware

http://whitenoise.evans.io/en/stable/#quickstart-for-django-apps
Yet django-heroku adds it before the security middleware.

Looks pretty straightforward as to why:
https://github.com/heroku/django-heroku/blob/8396b5544c36274942ee6d16ab46d4cddcdd3b4b/django_heroku/core.py#L101-L105
For a fix, you could do something like this instead (looking for feedback on approach before submitting a PR). Not as clean, but does operate within the expected parameters of whitenoise. You could make an assumption about SecurityMiddleware always being first in the list, but that seems fraught.
try:
    MIDDLEWARE_CLASSES = list(config['MIDDLEWARE_CLASSES'])
    MIDDLEWARE_CLASSES.insert(
        MIDDLEWARE_CLASSES.index('django.middleware.security.SecurityMiddleware') + 1,
                                 'whitenoise.middleware.WhiteNoiseMiddleware')
    config['MIDDLEWARE_CLASSES'] = tuple(MIDDLEWARE_CLASSES)
except KeyError:
    MIDDLEWARE = list(config['MIDDLEWARE'])
    MIDDLEWARE.insert(
        MIDDLEWARE.index('django.middleware.security.SecurityMiddleware') + 1,
                         'whitenoise.middleware.WhiteNoiseMiddleware')
    config['MIDDLEWARE'] = tuple(MIDDLEWARE)

You have to go out to a new variable because list.index modifies the original list, rather than returning the newly modified list, so the original list(config...) won't work since that created an on-the-fly reference.

+1

Any updates on this so far? It doesn't seem to work with Django 2.2 :disappointed:


refactor: move to new cli setup

#158  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @pevisscher and the rest of your teammates on  Graphite


add an optional email address support to class roster

The email address parameter has been updated to the user/setup api. If provided, it will be used instead of the requester's email address.

What exactly is this paramter called? Can you update the documentation? https://github.com/ohmage/server/wiki/User-Manipulation#userSetup

Fixed @ https://github.com/mobilizingcs/classes/commit/fa0e7cbd5dd16372b3d095273b1b7064ee8a4aa9.


OCPEDGE-1383: fix: general repo cleanup to pull the repo in-line with our standard setups

Vendoring
Containerfile updates
Makefile updates
Removed cruft

_OLD directory
editor config file

OWNERS file

closing in favor of doing this upstream


fix null pointer exception in htlc config

Codecov Report

Merging #161 into dev will decrease coverage by 0.02%.
The diff coverage is 0.00%.


A error whit doc.data()

I just cloned the project and received this error:

I would like your help. Could you explain what "doc.data()" is. And what could be the error. I would be really thankful

of course whenever you don't understand something post an issue about it.
@caiobraga please tell me in which file and line this error is happening also did you set up a firebase project and copied and pasted the firebase config object in "firebase.js" file ???

thak you for the time anjd atention, i did the configuration of firebase.js. the error appeared in the line 111 of the src/App.js

I also changed the databaseURL in the backend/index.js file to the one that I have in firebase.

Ok I know what's the problem.
you see this app caches the frontend assets and in firestore there should be a collection "version" and there is a document in it "version" which has one property "version" which holds a number now you can give it any number and if you do some changes in your app and deploy them just increment that number and your frontend will automatically get the new assets.
So in order to fix your error create that collection.

Do it like this:

I will try it. come back if the answer in a second

iI see an upgrade!!!
that is the response now

what are the permissions in the firebase? i let them as a test

can that be the error?

Show at what file and line that error happened.
But I think it's from your firebase config or security rules because if you allow reads for authenticated users only the app won't be able to read the version collection so change the security rules

this is my rules:
rules_version = '2';   service cloud.firestore {     match /databases/{database}/documents {       match /{document=**} {         allow write, read: if (request.auth.uid != null);       }   		match /version/version {          allow read;          allow write: if false;       }     }   }
as you can see I allow read for the version collection

it was different than mine, but it was not it.

CONFIGURATION_NOT_FOUND is the error, so I guess is some mistake that I made in the configuration process.
the databaseURL that I changed was from the real-time database. is this a problem?

I get it now, it must be it then. thank you very much.

just an update. I found the second error, it was because I did not set the sign-in method in firebase. Sorry for the bad English btw. I am Brazilian so..

No problem man you're welcome


Fail to execute the command "Azure Static Web Apps: Install or Update Azure Static Web Apps CLI" on Mac & Linux

OS: M1/Linux
Build Version: 20230119.3
Regression: Not a regression
Repro Steps:

F1 -> Azure Static Web Apps: Install or Update Azure Static Web Apps CLI.
Check whether succeeds to execute the command.

Expect:
Succeed to execute the command.
Actual:
Fail to execute the command.

More Info:

This issue does not reproduce on Windows.
Succeed to install the Azure Static Web Apps CLI with the same command which add "sudo" manually.
This issue also reproduces when executing command "Azure Static Web Apps: Uninstall Azure Static Web Apps CLI".

The error is pretty clear about needing to rerun the command with 'sudo'.  This error only occurs when npm isn't installed in the correct directory for privilege purposes.


Support the gap property

Use case
The gap property is one of the greatest properties to be added to CSS in the last decade and goes hand-in-hand with flex layout.
Not having it is jarring to web developers, and solutions like SizeBox in between feels ugly, verbose, and primitive - the whole point of gap is that you don't have to check the index of your elements and add special handling:

if it's the first element
if it's the last element
if it's the only element

Making the user do that whenever they use a Row or Column is messy, inelegant, and time consuming.
React native and any modern flex layout engine like Dioxus' Taffy or Lapce's Floem support the gap property:
https://reactnative.dev/docs/flexbox#row-gap-column-gap-and-gap
https://github.com/DioxusLabs/taffy/blob/main/examples/flexbox_gap.rs#L15
https://github.com/lapce/floem/blob/341afd255f98ca431e4f615864daa4dbcc057501/examples/widget-gallery/src/slider.rs#L31
Proposal
Support the gap property

This would solve it elegantly also I think: letsar/gap#19

Oh cool yes it would, I’ll track that PR thanks

Closing based on above comment.


Fix build with clang assembler

Fixes build bug introduced by https://github.com/openssl/openssl/commit/ccceeb48000d5fae95f38d2c4dd02cdd89ca1ee1
Build is no longer possible with clang (used by oss-fuzz).
My steps to reproduce are on Linux ubuntu:
export CC=clang
./config no-poly1305 no-shared no-threads
make build_generated libcrypto.a

gives following error :
CC="clang" /usr/bin/perl crypto/aes/asm/aes-x86_64.pl "elf" -I. -Iinclude -Iproviders/common/include -Iproviders/implementations/include -Icrypto/include -fPIC -m64 -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG  -DAES_ASM -DBSAES_ASM -DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DPADLOCK_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DX25519_ASM  crypto/aes/aes-x86_64.s
clang -fPIC -m64 -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG  -c -o crypto/aes/libcrypto-lib-aes-x86_64.o crypto/aes/aes-x86_64.s
crypto/aes/aes-x86_64.s:2659:33: error: expected string in directive
        .section ".note.gnu.property", #alloc

Reason is that clang does not answer to arguments -Wa,-v cf https://bugs.llvm.org/show_bug.cgi?id=24200
Proposed workaround is to test for clang compiler directly

From a copyright an licensing perspective, I don't think this can be called a trivial change (you'd be surprised how low the bar can be).  The rest of @openssl/omc may disagree, though, but to be on the safe side, it would be best with a signed CLA, see https://www.openssl.org/policies/cla.html

it would be best with a signed CLA

I had signed a CLA some time ago (like 2 years)
I force pushed with the changed commit author to have the same email as in the CLA...
Is it ok ?

I force pushed with the changed commit author to have the same email as in the CLA...
Is it ok ?

Oh, sorry, my update of this discussion page didn't include that update when I wrote my comment.  Sorry for the bother.
Yes, all OK.

Please mark this as URGENT  A major supported platform is now completely broken!

Merging now

Merged
a24e62f54b48d01832fd0b80f97115927a777a0f Fix build with clang assembler


Fivetran Sensor shows incorrect sync status

There is an issue that we have been seeing every 2-3 weeks now across multiple kinds of connectors
The issue is:
Sometimes, the sync status from the the Fivetran Sensor is not correctly updated even if the sync status is updated in the UI dashboard.
Eg: Let's say when a sync is triggered, the sync status in the UI dashboard would change to scheduled, then to syncing and then to synced. All within a few mins.
But the sync status from the sensor would still remain stuck at scheduled. We have a task timeout of 1 hour. So, after one hour the task automatically fails. Then we go look in the UI dashboard and see that everything is normal, there were not errors during the sync
fivetran_sync_google_ads_fivetran_wait_for_google_ads_20220701_sync_2023-02-09T07_45_00+00_00_1 (1).log
Can you please let us know why is there discrepancy in the status returned by the APi response via the sensor and the status in the UI dashboard?
I'm attaching logs from our Airflow Task for clarity

Any updates on this?
It happened again today for Ssalesforce connector. The status was stuck at rescheduled forever until Airflow times out after 1 hour
[2023-02-20, 09:49:19 UTC] {{standard_task_runner.py:82}} INFO - Running: ['airflow', 'tasks', 'run', 'fivetran_sync_bedrock', 'fivetran_wait_for_bedrock_sync', 'scheduled__2023-02-20T07:49:00+00:00', '--job-id', '88561', '--raw', '--subdir', 'DAGS_FOLDER/fivetran/fivetran_ingress.py', '--cfg-path', '/tmp/tmp2x44x5s8'] [2023-02-20, 09:49:19 UTC] {{standard_task_runner.py:83}} INFO - Job 88561: Subtask fivetran_wait_for_bedrock_sync [2023-02-20, 09:49:20 UTC] {{task_command.py:376}} INFO - Running <TaskInstance: fivetran_sync_bedrock.fivetran_wait_for_bedrock_sync scheduled__2023-02-20T07:49:00+00:00 [running]> on host ip-172-22-26-42.ec2.internal [2023-02-20, 09:49:20 UTC] {{taskinstance.py:1590}} INFO - Exporting the following env vars: AIRFLOW_CTX_DAG_OWNER=airflow AIRFLOW_CTX_DAG_ID=fivetran_sync_bedrock AIRFLOW_CTX_TASK_ID=fivetran_wait_for_bedrock_sync AIRFLOW_CTX_EXECUTION_DATE=2023-02-20T07:49:00+00:00 AIRFLOW_CTX_TRY_NUMBER=1 AIRFLOW_CTX_DAG_RUN_ID=scheduled__2023-02-20T07:49:00+00:00 [2023-02-20, 09:49:20 UTC] {{base.py:71}} INFO - Using connection ID 'data_fivetran' for task execution. [2023-02-20, 09:49:24 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = scheduled [2023-02-20, 09:49:55 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:50:28 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:51:00 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:51:31 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:52:03 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:52:35 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:53:07 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:53:39 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:54:11 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:54:43 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:55:15 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:55:47 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:56:19 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:56:51 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:57:23 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:57:55 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:58:27 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:58:59 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 09:59:31 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:00:03 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:00:35 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:01:07 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:01:39 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:02:11 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:02:43 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:03:15 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:03:47 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:04:19 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:04:51 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:05:23 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:05:55 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:06:27 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:06:59 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:07:31 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:08:03 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:08:35 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:09:07 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:09:39 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:10:11 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:10:44 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:11:15 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:11:47 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:12:19 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:12:51 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:13:23 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:13:55 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:14:27 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:14:59 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:15:31 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:16:03 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:16:35 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:17:07 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:17:39 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:18:11 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:18:43 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:19:15 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:19:47 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:20:19 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:20:51 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:21:23 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:21:55 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:22:27 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = syncing [2023-02-20, 10:22:59 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:23:33 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:24:05 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:24:37 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:25:09 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:25:41 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:26:13 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:26:45 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:27:17 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:27:49 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:28:21 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:28:54 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:29:25 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:29:57 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:30:29 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:31:01 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:31:33 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:32:06 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:32:43 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:33:14 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:33:46 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:34:18 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:34:50 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:35:22 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:35:54 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:36:26 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:36:58 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:37:30 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:38:02 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:38:34 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:39:06 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:39:38 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:40:10 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:40:42 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:41:17 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:41:49 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:42:22 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:42:53 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:43:25 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:43:57 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:44:30 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:45:02 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:45:34 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:46:06 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:46:38 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:47:10 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:47:42 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:48:14 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:48:46 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:49:18 UTC] {{fivetran.py:388}} INFO - Connector "terrace_lurking": sync_state = rescheduled [2023-02-20, 10:49:20 UTC] {{timeout.py:68}} ERROR - Process timed out, PID: 2206 [2023-02-20, 10:49:20 UTC] {{taskinstance.py:1851}} ERROR - Task failed with exception Traceback (most recent call last):   File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/sensors/base.py", line 211, in execute     time.sleep(self._get_next_poke_interval(started_at, run_duration, try_number))   File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/utils/timeout.py", line 69, in handle_timeout     raise AirflowTaskTimeout(self.error_message) airflow.exceptions.AirflowTaskTimeout: Timeout, PID: 2206 [2023-02-20, 10:49:20 UTC] {{taskinstance.py:1401}} INFO - Marking task as FAILED. dag_id=fivetran_sync_bedrock, task_id=fivetran_wait_for_bedrock_sync, execution_date=20230220T074900, start_date=20230220T094919, end_date=20230220T104920 [2023-02-20, 10:49:20 UTC] {{logging_mixin.py:137}} WARNING - /usr/local/airflow/.local/lib/python3.10/site-packages/airflow/providers/slack/operators/slack.py:66 DeprecationWarning: Provide token as hook argument deprecated by security reason and will be removed in a future releases. Please specify token in Slack APIconnection. [2023-02-20, 10:49:20 UTC] {{logging_mixin.py:137}} WARNING - /usr/local/airflow/.local/lib/python3.10/site-packages/airflow/providers/slack/operators/slack.py:66 FutureWarning: You have not set parameterslack_conn_id. Currently Slack API connection id optional but in a future release it will mandatory. [2023-02-20, 10:49:20 UTC] {{standard_task_runner.py:100}} ERROR - Failed to execute job 88561 for task fivetran_wait_for_bedrock_sync (Timeout, PID: 2206; 2206) [2023-02-20, 10:49:20 UTC] {{local_task_job.py:159}} INFO - Task exited with return code 1

Any updates on this?
It happened again today for Google connector and Bing connector. The status was stuck at scheduled forever until Airflow times out after 1 hour
Bing logs
INFO - Running <TaskInstance: fivetran_sync_bingads_tcr.fivetran_wait_for_bingads_tcr_sync scheduled__2023-02-24T09:37:00+00:00 [running]> on host ip-172-22-13-175.ec2.internal
[2023-02-24, 05:39:10 CST] {{taskinstance.py:1590}} INFO - Exporting the following env vars:
AIRFLOW_CTX_DAG_OWNER=airflow
AIRFLOW_CTX_DAG_ID=fivetran_sync_bingads_tcr
AIRFLOW_CTX_TASK_ID=fivetran_wait_for_bingads_tcr_sync
AIRFLOW_CTX_EXECUTION_DATE=2023-02-24T09:37:00+00:00
AIRFLOW_CTX_TRY_NUMBER=1
AIRFLOW_CTX_DAG_RUN_ID=scheduled__2023-02-24T09:37:00+00:00
[2023-02-24, 05:39:10 CST] {{base.py:71}} INFO - Using connection ID 'data_fivetran' for task execution.
[2023-02-24, 05:39:11 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:39:41 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:40:12 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:40:42 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:41:12 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:41:43 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:42:13 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:42:43 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:43:14 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:43:44 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:44:14 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:44:47 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:45:17 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:45:47 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:46:18 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:46:48 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:47:18 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:47:49 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:48:19 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:48:49 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:49:19 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:49:50 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:50:20 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:50:50 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:51:21 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:51:51 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:52:22 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:52:52 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:53:22 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:53:52 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:54:23 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:54:53 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:55:23 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:55:54 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:56:24 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:56:54 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:57:25 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:57:55 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:58:25 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:58:56 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:59:26 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 05:59:56 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:00:27 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:00:57 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:01:27 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:01:57 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:02:28 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:02:58 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:03:28 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:03:59 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:04:29 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:04:59 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:05:30 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:06:00 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:06:30 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:07:01 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:07:31 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:08:01 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:08:32 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:09:02 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:09:32 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:10:02 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:10:33 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:11:03 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:11:33 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:12:04 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:12:34 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:13:05 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:13:35 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:14:06 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:14:36 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:15:06 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:15:36 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:16:07 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:16:37 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:17:07 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:17:38 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:18:08 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:18:38 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:19:09 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:19:39 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:20:09 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:20:39 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:21:10 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:21:40 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:22:10 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:22:41 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:23:11 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:23:41 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:24:12 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:24:42 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:25:12 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:25:43 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:26:13 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:26:43 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:27:14 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:27:44 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:28:14 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:28:45 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:29:15 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:29:45 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:30:16 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:30:46 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:31:16 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:31:46 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:32:17 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:32:47 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:33:17 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:33:48 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:34:18 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:34:49 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:35:19 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:35:49 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:36:20 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:36:50 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:37:20 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:37:51 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:38:21 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:38:51 CST] {{fivetran.py:388}} INFO - Connector "clubbing_incurred": sync_state = scheduled
[2023-02-24, 06:39:10 CST] {{timeout.py:68}} ERROR - Process timed out, PID: 5759
[2023-02-24, 06:39:10 CST] {{taskinstance.py:1851}} ERROR - Task failed with exception
Traceback (most recent call last):
File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/sensors/base.py", line 211, in execute
time.sleep(self._get_next_poke_interval(started_at, run_duration, try_number))
File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/utils/timeout.py", line 69, in handle_timeout
raise AirflowTaskTimeout(self.error_message)
airflow.exceptions.AirflowTaskTimeout: Timeout, PID: 5759
But Fivetran dashboard says all good during the sync

Recommend to follow this doc as a guide and use FivetranOperator + FivetranSensor in the same dag.  Use the xcom so that the sensor is looking for the correct sync event that is passed to the xcom by FivetranOperator.  https://www.fivetran.com/blog/orchestrating-elt-in-airflow-catching-every-sync-with-xcom
Guessing that the rescheduled problem is because of hitting API throttling on a connector.  On the UI, the rescheduled syncs are colored purple on the timeline.  I'm not aware of a way to handle for that but am interested to find one.

I just saw this. Will look into it and close the issue if that serves the purpose. Thanks!

I implemented this solution and it it's been working fine for all situations except for reschedules.
Airflow is still timing out after our time out period of 1 hour whenever the connector is rescheduled.
Do we have a solution for reschedules yet?

Any updates?