Fix crash if commissioning is canceled while waiting on an attestation delegate.

When we extend the fail-safe after device attestation before calling into the delegate, we ended up with a dangling mInvokeCancelFn after the command finished and until CommissioningStageComplete().  That last would not happen until our delegate called back into us to continue commissioning.
If an attempt was made to cancel commissioning during that time interval, we would end up crashing.

This is causing crashes when pairing in CSG tests, marking hotfix


bgr vs rgb color (regression)

I compiled 2.0.0-dev (git 3b83526) on a Solaris 11.3 (x86). I see inverted colors (red and blue swapped). Seems to be a regression of issue #297 (xfreerdp displays inverted colors).
Any suggestion how to fix that are really appreciated.
Thx
Carsten

@mpicjohn check xf_get_local_color_format it seems to detect the wrong local color format in your case.

Hi  akallabeth,
thanks for the hint. I could fix the issue by hard coding
DstFormat = PIXEL_FORMAT_RGBX32;
in xf_graphics.c
works for me at the moment. I will try to figure out why DstFormat is not detected correctly when I find some time...
thx
Carsten

@mpicjohn Glad it works. Would be great to find the autodetection issue with your configuration, so hope to hear from you :)


Upgrade to llvm 6.0.0 redux

@allieoop packaged the freshly released LLVM 6.0.0 toolchain in mason. This updates node-cpp-skel to start using (and testing) it. If this works then all downstream deps will be encouraged to update too (by forward porting to the latest skel framework).
This change specifically:

Uses new packages for llvm 6.0.0 (and sub-packages) mapbox/mason#600 (@allieoop)
Uses bundled pyyaml such that, when using >= llvm 6, we do not need to manually install an external pyyaml to be able to use run-clang-tidy.py (refs mapbox/node-cpp-skel#106)

Note: this PR replaces https://github.com/mapbox/node-cpp-skel/pull/118
/cc @allieoop

This is currently blocked by:
 ./mason_packages; ./node_modules/.bin/mason-js link
info Symlinked:  /Users/dane/projects/node-cpp-skel/mason_packages/headers/protozero/1.6.1 to  /Users/dane/projects/node-cpp-skel/mason_packages/.link
ERR! Error: EACCES: permission denied, unlink '/Users/dane/projects/node-cpp-skel/mason_packages/.link/include/c++/v1/__bit_reference'
make[1]: *** [mason_packages/.link] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2

Which is ticketed at https://github.com/mapbox/mason-js/issues/58. In short, this is not a problem with LLVM 6.0.0, but appears to be a problem in mason-js that surfaces with LLVM 6.0.0.

Once the above error is solved, we'll hit 2 others related to new features of clang-tidy detecting existing issues in our code:
readability-redundant-member-init
These are captured at https://github.com/mapbox/node-cpp-skel/pull/118#issuecomment-384127157 and should be fixable with:
diff --git a/src/object_async/hello_async.cpp b/src/object_async/hello_async.cpp
index b871a41..22f66bc 100644
--- a/src/object_async/hello_async.cpp
+++ b/src/object_async/hello_async.cpp
@@ -155,7 +155,7 @@ struct AsyncHelloWorker : Nan::AsyncWorker // NOLINT to disable cppcoreguideline

     AsyncHelloWorker(bool louder, const std::string* name,
                      Nan::Callback* cb)
-        : Base(cb), result_{}, louder_{louder}, name_{name} {}
+        : Base(cb), louder_{louder}, name_{name} {}

     // The Execute() function is getting called when the worker starts to run.
     // - You only have access to member variables stored in this worker.
@@ -186,7 +186,7 @@ struct AsyncHelloWorker : Nan::AsyncWorker // NOLINT to disable cppcoreguideline
         callback->Call(argc, static_cast<v8::Local<v8::Value>*>(argv));
     }

-    std::string result_;
+    std::string result_{};
     const bool louder_;
     // We use a pointer here to avoid copying the string data.
     // This works because we know that the original string we are
diff --git a/src/standalone_async/hello_async.cpp b/src/standalone_async/hello_async.cpp
index 68fb652..72270ee 100644
--- a/src/standalone_async/hello_async.cpp
+++ b/src/standalone_async/hello_async.cpp
@@ -72,7 +72,7 @@ struct AsyncHelloWorker : Nan::AsyncWorker {
     using Base = Nan::AsyncWorker;

     AsyncHelloWorker(bool louder, Nan::Callback* cb)
-        : Base(cb), result_{}, louder_{louder} {}
+        : Base(cb), louder_{louder} {}

     // The Execute() function is getting called when the worker starts to run.
     // - You only have access to member variables stored in this worker.
@@ -105,7 +105,7 @@ struct AsyncHelloWorker : Nan::AsyncWorker {
         callback->Call(argc, static_cast<v8::Local<v8::Value>*>(argv));
     }

-    std::string result_;
+    std::string result_{};
     const bool louder_;
 };

fuchsia-default-arguments
These are discussed in https://github.com/mapbox/node-cpp-skel/pull/118#issuecomment-384128216 and should be fixable with:
diff --git a/src/object_async/hello_async.cpp b/src/object_async/hello_async.cpp
index b871a41..11022f5 100644
--- a/src/object_async/hello_async.cpp
+++ b/src/object_async/hello_async.cpp
@@ -275,7 +275,7 @@ void HelloObjectAsync::Init(v8::Local<v8::Object> target) {

     // Create the HelloObject
     auto fnTp = Nan::New<v8::FunctionTemplate>(
-        HelloObjectAsync::New); // Passing the HelloObject::New method above
+        HelloObject::New, v8::Local<v8::Value>()); // Passing the HelloObject::New method above
     fnTp->InstanceTemplate()->SetInternalFieldCount(
         1);                     // It's 1 when holding the ObjectWrap itself and nothing else
     fnTp->SetClassName(whoami); // Passing the Javascript string object above
diff --git a/src/object_sync/hello.cpp b/src/object_sync/hello.cpp
index f6df549..b9006ed 100644
--- a/src/object_sync/hello.cpp
+++ b/src/object_sync/hello.cpp
@@ -142,7 +142,7 @@ void HelloObject::Init(v8::Local<v8::Object> target) {

     // Officially create the HelloObject
     auto fnTp = Nan::New<v8::FunctionTemplate>(
-        HelloObject::New); // Passing the HelloObject::New method above
+        HelloObject::New, v8::Local<v8::Value>()); // Passing the HelloObject::New method above
     fnTp->InstanceTemplate()->SetInternalFieldCount(
         1);                     // It's 1 when holding the ObjectWrap itself and nothing else
     fnTp->SetClassName(whoami); // Passing the Javascript string object above

I'm getting that one error where a make tidy removes a parameter and leaves the comma. I think we documented this issue somewhere and maybe just manually fixed it the last time it came up.  Do you remember this @springmeyer?
I'll look into how we turn this check off in our .clang-tidy file.
diff --git a/src/object_async/hello_async.cpp b/src/object_async/hello_async.cpp
index b871a41..adbe8ea 100644
--- a/src/object_async/hello_async.cpp
+++ b/src/object_async/hello_async.cpp
@@ -155,7 +155,7 @@ struct AsyncHelloWorker : Nan::AsyncWorker // NOLINT to disable cppcoreguideline

     AsyncHelloWorker(bool louder, const std::string* name,
                      Nan::Callback* cb)
-        : Base(cb), result_{}, louder_{louder}, name_{name} {}
+        : Base(cb), , louder_{louder}, name_{name} {}

     // The Execute() function is getting called when the worker starts to run.
     // - You only have access to member variables stored in this worker.
diff --git a/src/standalone_async/hello_async.cpp b/src/standalone_async/hello_async.cpp
index 68fb652..9d09105 100644
--- a/src/standalone_async/hello_async.cpp
+++ b/src/standalone_async/hello_async.cpp
@@ -72,7 +72,7 @@ struct AsyncHelloWorker : Nan::AsyncWorker {
     using Base = Nan::AsyncWorker;

     AsyncHelloWorker(bool louder, Nan::Callback* cb)
-        : Base(cb), result_{}, louder_{louder} {}
+        : Base(cb), , louder_{louder} {}

maybe just manually fixed it the last time it came up.

The manual fix I lifted into a diff above at:  https://github.com/mapbox/node-cpp-skel/pull/129#issuecomment-385544411. So I recommend applying that - please go ahead and do that to this branch.

I think we documented this issue somewhere and

Not documented anywhere beyond this ticket.
But I did confirm that the problem does not happen with LLVM head (future 7.0.0) on my machine, so I think the manual fix for now is okay since we'll eventually not get bitten by it again. Do you agree? Or maybe we should document this gocha in https://github.com/mapbox/node-cpp-skel/blob/master/docs/extended-tour.md#clang-tidy?

But I did confirm that the problem does not happen with LLVM head (future 7.0.0) on my machine

mentioned at https://github.com/mapbox/node-cpp-skel/pull/118#issuecomment-384841898

I agree, manually fixing the clang-tidy change is the right step since we know this won't be an issue later on when we use LLVM 7.0.0. Thanks for confirming!

@springmeyer - I made the change we discussed above and now I think this change is ready to be merged in.
Here's the official 👍

@allieoop this looks good. One thing is that this branch (I think) is still hitting clang-tidy issues. They are not failing travis due to https://github.com/mapbox/node-cpp-skel/issues/105, but they are visible in the logs: https://travis-ci.org/mapbox/node-cpp-skel/jobs/388585932#L1095 (and if you run locally). I'm 👍 on merging and then ticketing a followup on fixing the clang-tidy issues. What do you think?

Yes, I agree this can be merged as we continue a conversation about #105 (I left some comments there). But before merging I'd like to confirm that:

We're both seeing 6 warnings being treated as errors, even though clang-tidy only acknowledges 3 of them.

The 6 errors (originally warnings) that I see are:
hello.cpp

error: calling a function that uses a default argument is disallowed
error: initializing non-owner 'object_sync::HelloObject *const' with a newly created 'gsl::owner<>'

hello_async.cpp:

error: calling a function that uses a default argument is disallowed
error: initializing non-owner 'object_async::HelloObjectAsync *const' with a newly created 'gsl::owner<>'
error: initializing non-owner 'object_async::AsyncHelloWorker *' with a newly created 'gsl::owner<>'
error: initializing non-owner 'standalone_async::AsyncHelloWorker *' with a newly created 'gsl::owner<>'

Yet clang-tidy prints:
3 warnings treated as errors

Do you know why only 3 are acknowledged in that statement? To make that there were actually 6 warnings, and not 3 warnings and 3 errors, I removed the line in our .clang-tidy file to treat warnings as errors and all 6 of those errors are indeed originally warnings.

The 6 errors are not easy to fix manually.

There are two different types of errors occurring:

Calling a function that uses a default argument, e.g. https://github.com/mapbox/node-cpp-skel/blob/master/src/object_sync/hello.cpp#L144 where we call Nan::New but we need to call this function. Since this is part of Nan code and outside of our control I don't see how to fix this error directly.

"Bad" initialization of non-owners with a newly created 'gsl::owner<>', e.g. https://github.com/mapbox/node-cpp-skel/blob/master/src/object_sync/hello.cpp#L72. Looks like this is part of clang-tidy's OwningMemoryCheck: https://github.com/llvm-mirror/clang-tools-extra/blob/master/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp#L316. I found some notes here: https://reviews.llvm.org/D36354 but I need more time to digest this and to figure out how a line of code like this auto* const self = new HelloObject(std::move(name)); sets it off.

Since this is part of Nan code and outside of our control I don't see how to fix this error directly.

I proposed above (see fuchsia-default-arguments) starting to be explicit and not depending on a default arg. That feels like a decent solution to me, you?

"Bad" initialization of non-owners with a newly created 'gsl::owner<>',

My feeling is that we don't want to use gls::owner and I would be up for ignoring this one in our .clang-tidy config since this is going to be very difficult to workaround (or at least I think when I've looked before it did not seem possible since we're dealing with the node API here). Maybe when we port to N-API this will go away...

Your fix to the clang-tidy fuchsia-default-arguments warning worked. So it turns out that clang-tidy is fine with calling functions that have parameters with default values and only cares whether or not those default values are used. So the guideline is to always pass a value in and never rely on defaults. (This is more a note to myself.)
To address the other warning, cppcoreguidelines-owning-memory, which I think is a good guideline I switched from using raw pointers to unique_ptrs e.g.:
-                    auto* const self = new HelloObjectAsync(std::move(name));
+                    const auto self = std::make_unique<HelloObjectAsync>(std::move(name));

We have one line of code that creates a raw pointer to a struct which I have clang ignore with the NOLINT comment. I do think because I think this check is helpful and worth keeping, but our AsyncHelloWorker struct might need some refactoring before it can work with unique_ptr which will need to call its constructor, e.g.
auto worker = std::make_unique<AsyncHelloWorker>(louder, &h->name_, new Nan::Callback{callback});

Update: It looks like Travis isn't finding c++14 which is why tests on Travis are failing so I'll have to into this. @springmeyer maybe you'll see what I'm doing wrong in my attempt to upgrade?

🙌 Congrats on landing this @allieoop - feels great to be providing more warning free, type safe, and memory-leak protected code code here, thanks to your hard work, methodical debugging, and using the latest LLVM release. The one followup I see is https://github.com/mapbox/node-cpp-skel/issues/141, which I've got on my radar for the coming days.

note: all the code improvements in this PR we kept but the actual LLVM version was reverted in #146


More generic execution API

Currently, JuliaWebAPI works for functions that are exported via process and take String parameters.
It may be useful to have a mechanism where arbitrary functions (maybe limited to those with String and int/float params)  could be executed via JSON and the APIInvoker.
cc: @tanmaykm @viralbshah Thoughts?

@aviks The current design is to have the registered method take all string parameters and delegate after converting appropriately. I was unable to come up with any other good mechanism to handle different parameter types and methods with multiple signatures. Can you elaborate if you have an alternate way to achieve this?

@aviks and I were talking about this a bit today. He is in Bangalore on Monday, and perhaps we can meet up and figure this out.

Great! I'll be away, but do ping me if needed.

So currently, parameters of different types work to the extent of primitive JSON types.. ie String, integers and floats. That is all we want at the moment, I think, without implementing our own IDL.
The other thing in this issue is the ability to invoke any function, rather than just those registered. However, that is policy question, the implementation is trivial. What do people feel about this?

This should not break existing implementations, because of the applicable check.
Outside this PR's scope, I wonder if it would be possible to use method reflection to handle more cases.
This handles a specific case of array types e.g. the test won't pass if called with [1 2; 3 4] instead of [1.0 2.0; 3.0 4.0].

Fixed by #40


[core] Support ChronVer

https://chronver.org/

For now only version parsing occurs which enables sorting tags.
Enforcing a given version matches the current date should be done at a later stage.


Add $TORO

Description
TORO COIN
pool_id
pool 1624

The checklist is useful for instructing on steps and tracking progress.
Please resolve conflicts and mark the token as unlisted.

Fix conflicts in new PR


CDPD-32469 Script should log with timestamp

IMO a good idea :+1:
Personally I'ld even create a log (log_info) function, so that any change (for ex. in the timestamp format) can be done in one place

IMO a good idea +1 Personally I'ld even create a log (log_info) function, so that any change (for ex. in the timestamp format) can be done in one place

I think there is a log_info in cdp/cdh script, although there are still lot of individual echo commands


failed to find shared library backend postgresql

Hi Everyone,
I get this error when i try to run my soci application.
failed to find shared library backend postgresql
I install via vcpkg.
libpq is installed via vcpkg too.
Please help

I ran into a problem similar to yours
program failed to find shared library backend mysql&sqlite3

It's difficult to diagnose problems with DLL loading remotely because there are many things that could go wrong (missing DLLs; missing DLL dependencies; mismatched 32/64 DLLs; ...), but it's usually very simple to debug it locally. Just run the program under debugger and look at the debug output messages. If this is not enough, enable "loader snaps" using gflags, this should really give you all the information that you need.

I also ran into the same problem as yours even if I use linux. (my backend is postgresql)
My application said below,

./test
soci error: Failed to find shared library for backend postgresql

It seems soci shared libraries are not built when soci package is added by vcpkg.
But shared libraries are able to be built when I manually built them according to the Instration
I'd like to manage packages by vcpkg if possible so I'd like know how to build soci shared libraries when I use vcpkg.
OS: Ubuntu 20.04
> vcpkg/vcpkg list
abseil:x64-linux                                   20211102.1       an open-source collection designed to augment th...
c-ares:x64-linux                                   1.17.2#2         A C library for asynchronous DNS requests
grpc:x64-linux                                     1.41.0           An RPC library and framework
grpc[codegen]:x64-linux                                             Build code generator machinery
libpq:x64-linux                                    12.9#1           The official database access API of postgresql
libpq[openssl]:x64-linux                                            support for encrypted client connections and ran...
libpq[zlib]:x64-linux                                               Use zlib (else --without-zlib)
openssl:x64-linux                                  1.1.1m#2         OpenSSL is an open source project that provides ...
protobuf:x64-linux                                 3.18.0#1         Protocol Buffers - Google's data interchange format
re2:x64-linux                                      2021-11-01       RE2 is a fast, safe, thread-friendly alternative...
soci:x64-linux                                     4.0.2            SOCI database access library
soci[postgresql]:x64-linux                                          Build postgresql backend
upb:x64-linux                                      2021-10-19       μpb (often written 'upb') is a small protobuf i...
vcpkg-cmake-config:x64-linux                       2022-01-30
vcpkg-cmake:x64-linux                              2022-01-19
zlib:x64-linux                                     1.2.11#13        A compression library

> fd libsoci --no-ignore
vcpkg/installed/x64-linux/lib/libsoci_empty.a
vcpkg/installed/x64-linux/lib/libsoci_core.a
vcpkg/installed/x64-linux/lib/libsoci_postgresql.a
vcpkg/packages/soci_x64-linux/lib/libsoci_empty.a
vcpkg/packages/soci_x64-linux/lib/libsoci_core.a
vcpkg/packages/soci_x64-linux/lib/libsoci_postgresql.a
vcpkg/installed/x64-linux/debug/lib/libsoci_empty.a
vcpkg/installed/x64-linux/debug/lib/libsoci_core.a
vcpkg/installed/x64-linux/debug/lib/libsoci_postgresql.a
vcpkg/buildtrees/soci/x64-linux-rel/lib/libsoci_empty.a
vcpkg/buildtrees/soci/x64-linux-rel/lib/libsoci_core.a
vcpkg/buildtrees/soci/x64-linux-rel/lib/libsoci_postgresql.a
vcpkg/buildtrees/soci/x64-linux-dbg/lib/libsoci_empty.a
vcpkg/buildtrees/soci/x64-linux-dbg/lib/libsoci_core.a
vcpkg/buildtrees/soci/x64-linux-dbg/lib/libsoci_postgresql.a
vcpkg/packages/soci_x64-linux/debug/lib/libsoci_empty.a
vcpkg/packages/soci_x64-linux/debug/lib/libsoci_core.a
vcpkg/packages/soci_x64-linux/debug/lib/libsoci_postgresql.a

If vcpkg really doesn't build shared libraries but still builds the core library to use them, it's a bug in the package and will need to be fixed there.
I don't think there is anything wrong with SOCI itself here, so closing.

I understand what you said. I think you are right. I shouldn't have posted the issue here.
Thank you.

Coming from the vcpkg issue: I think it's mostly a misunderstanding of vcpkg.
In the world of vcpkg, libraries are ususally build static on linux systems. This is because all libraries are build with vcpkg and there isn't such a good distribution of shared linux libraries and users often run into RPATH issues. (conflict between system and distributed libs).
vcpkg builds the plugins in a static manner which needs other actions: https://github.com/SOCI/soci/issues/497 .
If you really want to build shared libraries on linux, you would need to use custom triplets.
There is a example for this https://github.com/microsoft/vcpkg/blob/7249fa4d64ead1428249895810146134be8eb881/docs/examples/overlay-triplets-linux-dynamic.md

Thank you very much @mathisloge . I'll check the comments.

It's me that was wrong. I didn't think I would like to have used shared libraries.
I have read the explanation, was able to find my mistake and got the problem solved: issuecomment-1050514543
Thank you very much, @mathisloge.

FWIW I just ran into the (almost) same issue. However, in my case the issue was that I was establishing a connection to the DB using a connection string á la postgresql://dbname=xyz .... However, I had a typo in the leading postgresql which caused SOCI to look for the wrong library name.
That of course was entirely a user-issue and not SOCI's fault - just wanted to document this scenario here, in case someone ends up making the same mistake as I did.

I just ran into the same problem. My case is that I used static link to the libsoci_core.a but when the program runs, it searches for the dynamic lib(libsoci_postgresql.so). I solved the problem by installing the dynamic lib in the system. SOCI uses dlopen() to load the dynamic lib of specific database backend.

I just ran into the same problem. My case is that I used static link to the libsoci_core.a but when the program runs, it searches for the dynamic lib(libsoci_postgresql.so). I solved the problem by installing the dynamic lib in the system. SOCI uses dlopen() to load the dynamic lib of specific database backend.

maybe this https://github.com/microsoft/vcpkg/issues/23213#issuecomment-1049707356 ?


tests: add a test for bug 6278

PR tests "run-as":

non-existent user
NULL user (empty user string)

Redmine ticket: https://redmine.openinfosecfoundation.org/issues/6278

Continues in #1412


docs(workflow): update the build directory as it isn't contextualized…

… by the working-directory

@dcvz hopefully this will fix the the docs publish. It looks like it's the problem based on this log. I had assumed that that command would also be contextualized by the working-directory that is set in the action, but it doesn't look like it is.

@jspizziri I also had to change some settings in the repo. Looks like this pushes to a deviated gh-pages branch so we have to set that as the source + ask it to read the root of the repo and not the docs folder.
It works now!


[9.x] Correct php doc setUser method

I do not understand the reason for using alias for Authenticatable interface !

I've sent in an alternative to this here: https://github.com/laravel/framework/pull/42027.


nullclient-s.gateway.messenger.live.com

        _skype = new SkypeImpl(Settings.Default.SkypeLogin, Settings.Default.SkypePassword);
        _skype.login();
        var dispatcherv = _skype.getEventDispatcher();
        dispatcherv.registerListener(new MessageListener(OnSkypeMessage));
        _skype.subscribe();

and then I got
Exception:Thrown: "nullclient-s.gateway.messenger.live.com" (java.net.UnknownHostException)
A java.net.UnknownHostException was thrown: "nullclient-s.gateway.messenger.live.com"

Imho, it's not right to initialize cloud as blank...
private HttpURLConnection registerEndpoint(String skypeToken)
...
HttpURLConnection connection = builder.build();
int code = connection.getResponseCode();
/* ------> need to be here ---->>> */
updateCloud(connection.getHeaderField("Location"));
        if (code >= 301 && code <= 303 || code == 307) {

...

If you are not in any cloud, then your cloud would be blank and that code would never be called. If you are in a cloud, then your blank cloud would be overwritten with your current one. I'm not sure what you mean?

Yep, thank you, I've caught it now


Update instructions are not clear

Hello,
I don’t understand how to update correctly from 1.5.1 to 1.6
I have only one Micro SD card which is inside, when i went to update page, i read that i need to download and flash the Micro SD card then press next, so my question is: do i need another Micro SD card? Or i can safely remove the Micro SD card while I’m in the update page?
Or do i need to shutdown the raspiblitz and overwrite the micro SD card?
Any help would be appreciated.
PS: i have only one Micro SD card

Just press update. After that you can download a backup for critical files. Then you see the following:

If you start the update: The RaspiBlitz will power down.   │
│ Once the LCD is white and no LEDs are blicking anymore:    │
│                                                            │
│ - Remove the Power from RaspiBlitz                         │
│ - Exchange the old with the new SD card                    │
│ - Connect Power back to the RaspiBlitz                     │
│ - Follow the instructions on the LCD                       │
│                                                            │
│ Do you have the SD card with the new version image ready   │
│ and do you WANT TO START UPDATE NOW?


end links #1

Per prior arrangement, if this PR needs approval, or if the commits need to be pulled into the private repo, only @eriklindeman should be notified. Thanks.

@dubiety

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

sign-off


April 1, 2021 release

Codecov Report

Merging #628 (ff276e3) into master (c2f3f0f) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #628   +/-   ##
=======================================
  Coverage   50.94%   50.94%
=======================================
  Files          30       30
  Lines        1180     1180
  Branches      154      154
=======================================
  Hits          601      601
  Misses        575      575
  Partials        4        4

Impacted Files
Coverage Δ

...bigquery-export/scripts/gen-schema-view/src/udf.ts
44.45% <ø> (ø)

storage-resize-images/functions/src/util.ts
100.00% <100.00%> (ø)


运行python出错

2022-12-16 17:47:27.297 | ERROR    | App.Event:private_Chat:347 - You can't write against a read only replica.

系统权限问题， Python 对该目录没有写入权限


Azcore retry has context cancelled

Bug Report

SDK versionlatest

output of go version 1.17

Potentially does not only affect azblob, but all parts of azure that uses https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/runtime/policy_retry with retry

Meaning, anywhere that attempts retry and reads a larger payload, this context cancelled error will exist

What happened?

Context cancelled error when setting RETRY config with TryTimeout > 0 of a larger file / payload
Which means that the azblob attempted to retry downloading

What did you expect or want to happen?

No context cancelled error when not retrying

How can we reproduce it?
How to reproduce: Here is the test file
Attempt to download a largish file, e.g. a 1MB picture

import (
	"context"
	"fmt"
	"io"
	"log"
	"net/http"
	"os"
	"testing"
	"time"

	"github.com/Azure/azure-sdk-for-go/sdk/azcore/policy"
	"github.com/Azure/azure-sdk-for-go/sdk/azcore/streaming"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
	"github.com/stretchr/testify/require"
)

func TestDownload(t *testing.T) {
	accountName := <acctName>
        accountKey := <acctKey>

	blobURL := fmt.Sprintf("https://%s.blob.core.windows.net/<blobName>", accountName)
	credential, err := azblob.NewSharedKeyCredential(accountName, accountKey)
	require.NoError(t, err)

	client := http.DefaultClient

	blobClient, err := azblob.NewBlobClientWithSharedKey(blobURL, credential, &azblob.ClientOptions{
		Transporter: client,
		Retry: policy.RetryOptions{
			MaxRetries:    3,
			TryTimeout:    120 * time.Second,
			RetryDelay:    time.Second,
			MaxRetryDelay: 3 * time.Second,
		},
	})
	require.NoError(t, err)

	contentLength := int64(0) // Used for progress reporting to report the total number of bytes being downloaded.

	// Download returns an intelligent retryable stream around a blob; it returns an io.ReadCloser.
	dr, err := blobClient.Download(context.Background(), nil)
	require.NoError(t, err)

	rs := dr.Body(nil)
	// NewResponseBodyProgress wraps the GetRetryStream with progress reporting; it returns an io.ReadCloser.
	stream := streaming.NewResponseProgress(
		rs,
		func(bytesTransferred int64) {
			log.Printf("Downloaded %d of %d bytes.\n", bytesTransferred, contentLength)
		},
	)
	defer func(stream io.ReadCloser) {
		err := stream.Close()
		if err != nil {
			log.Fatal(err)
		}
	}(stream) // The client must close the response body when finished with it

	file, err := os.Create("test.jpg") // Create the file to hold the downloaded blob contents.
	require.NoError(t, err)
	defer func(file *os.File) {
		err := file.Close()
		require.NoError(t, err)
	}(file)

	written, err := io.Copy(file, stream) // Write to the file by reading from the blob (with intelligent retries).
	require.NoError(t, err)
	t.Logf("Wrote %d bytes.\n", written)
}

Error:
2022/04/29 12:14:39 Downloaded 3542 of 0 bytes.
2022/04/29 12:14:39 Downloaded 15830 of 0 bytes.
test_test.go:70:
        	Error Trace:	test_test.go:70
        	Error:      	Received unexpected error:
        	            	context canceled
        	Test:       	TestDownload
--- FAIL: TestDownload (0.27s)

When setting  TryTimeout:    0, (which disables retries) the download will succeed.
2022/04/29 12:25:41 Downloaded 3542 of 0 bytes.
2022/04/29 12:25:41 Downloaded 15830 of 0 bytes.
2022/04/29 12:25:41 Downloaded 32214 of 0 bytes.
2022/04/29 12:25:41 Downloaded 48598 of 0 bytes.
2022/04/29 12:25:41 Downloaded 64982 of 0 bytes.
2022/04/29 12:25:41 Downloaded 81366 of 0 bytes.
2022/04/29 12:25:41 Downloaded 97750 of 0 bytes.
2022/04/29 12:25:41 Downloaded 114134 of 0 bytes.
2022/04/29 12:25:41 Downloaded 130518 of 0 bytes.
2022/04/29 12:25:41 Downloaded 146902 of 0 bytes.
2022/04/29 12:25:41 Downloaded 163286 of 0 bytes.
2022/04/29 12:25:41 Downloaded 179670 of 0 bytes.
2022/04/29 12:25:41 Downloaded 180257 of 0 bytes.
    test_test.go:71: Wrote 180257 bytes.
--- PASS: TestDownload (0.30s)

What is the error:
In https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/runtime/policy_retry.go#L123-L131
Especially this line: https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/runtime/policy_retry.go#L130
The context is cancelled before returning the body for reading by the user of the library.
Difference from azure-storage-blob-go:
https://github.com/Azure/azure-storage-blob-go/blob/master/azblob/zc_policy_retry.go#L272
Does not cancel the context when doing the request, instead returns a custom reader where closing the reader will also cancel the context.

Possibly related to this issue too: https://github.com/Azure/azure-sdk-for-go/issues/17670, but not just for azstorage

Fixed in the upcoming<EMAIL_ADDRESS>release.  Thanks for the detailed bug report.


Removed duplicate Spotify.audio_analysis

Hey! I am hosting a new master branch for this repo since the old creator has been MIA for 2 years. Hoping to get this repo back on it's feet and in good standing. I've been working on updating tests and adding all new functionality and have merged some of the PR's that I thought were sufficient for merging. If your PR didn't make it, resubmit it please.
Thanks!
https://github.com/Harrison97/spotipy

Fixed as part of https://github.com/plamere/spotipy/pull/414