Android Build Failed to list versions for com.transistorsoft:tsbackgroundfetch

Your Environment

Plugin version<EMAIL_ADDRESS><EMAIL_ADDRESS>

Platform: Android

Device OS version: Simulator Pixel 4 API 31

Device manufacturer / model: Simulator

XCode version: not using for iOS

Capacitor info (npx cap doctor)
Latest Dependencies:
@capacitor/cli: 5.0.3
@capacitor/core: 5.0.3
@capacitor/android: 5.0.3
@capacitor/ios: 5.0.3

Installed Dependencies:
@capacitor/ios: not installed
@capacitor/cli: 5.0.3
@capacitor/core: 5.0.3
@capacitor/android: 5.0.3

Plugin config provided to #ready:

    BackgroundGeolocation.ready({
      // Geolocation Config
      desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
      distanceFilter: 10,
      // Activity Recognition
      stopTimeout: 5,
      // Application config
      debug: true, // <-- enable this hear sounds for background-geolocation life-cycle.
      logLevel: BackgroundGeolocation.LOG_LEVEL_VERBOSE,
      stopOnTerminate: false,   // <-- Allow the background-service to continue tracking when user closes the app.
      startOnBoot: true,        // <-- Auto start tracking when device is powered-up.
    }).then((state) => {
      // BackgroundGeolocation is now ready to use.
      this.ready = true;
    });

Expected Behavior
It should compile on Android Simulator and give beep sound.
Actual Behavior
Project start building on Android Studio and in the middle build failed saying Failed to list versions for com.transistorsoft:tsbackgroundfetch
Steps to Reproduce

Create ionic capacitor app
Install the plugin as mention in document
Setup Android as mention in documentation
Run the project in Android Studio Flamingo | 2022.2.1 Patch 1 which has AGP 8.0.2 , Gradle 7.0.2, Java version 17

Context
Trying to run the project on Simulator through Android Studio
Debug logs

Logs

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:checkDebugAarMetadata'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:checkDebugAarMetadata'.
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)

Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:170)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:146)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.executeGetOrHead(HttpClientHelper.java:135)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performRequest(HttpClientHelper.java:105)
	... 157 more
Caused by: java.net.SocketTimeoutException: Connect timed out
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	... 169 more
Cause 2: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
Required by:
    project :app > project :transistorsoft-capacitor-background-geolocation
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Skipped due to earlier error

==============================================================================

2: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:mapDebugSourceSetPaths'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:mapDebugSourceSetPaths'.
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	...
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:170)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:146)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.executeGetOrHead(HttpClientHelper.java:135)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performRequest(HttpClientHelper.java:105)
	... 157 more
Caused by: java.net.SocketTimeoutException: Connect timed out
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	... 169 more
Cause 2: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
Required by:
    project :app > project :transistorsoft-capacitor-background-geolocation
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Skipped due to earlier error

==============================================================================

3: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:mergeDebugResources'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:mergeDebugResources'.
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	...
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:170)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:146)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.executeGetOrHead(HttpClientHelper.java:135)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performRequest(HttpClientHelper.java:105)
	... 157 more
Caused by: java.net.SocketTimeoutException: Connect timed out
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	... 169 more
Cause 2: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
Required by:
    project :app > project :transistorsoft-capacitor-background-geolocation
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Skipped due to earlier error

==============================================================================

4: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:processDebugMainManifest'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:170)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:146)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.executeGetOrHead(HttpClientHelper.java:135)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performRequest(HttpClientHelper.java:105)
	... 157 more
Caused by: java.net.SocketTimeoutException: Connect timed out
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	... 169 more
Cause 2: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
Required by:
    project :app > project :transistorsoft-capacitor-background-geolocation
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Skipped due to earlier error

==============================================================================

5: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':transistorsoft-capacitor-background-geolocation:compileDebugJavaWithJavac'.
> Could not resolve all files for configuration ':transistorsoft-capacitor-background-geolocation:debugCompileClasspath'.
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':transistorsoft-capacitor-background-geolocation:compileDebugJavaWithJavac'.
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	...
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:380)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:49)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
Required by:
    project :transistorsoft-capacitor-background-geolocation
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Skipped due to earlier error

==============================================================================

6: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:mergeDebugAssets'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:mergeDebugAssets'.
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	...
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:170)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performHttpRequest(HttpClientHelper.java:146)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.executeGetOrHead(HttpClientHelper.java:135)
	at org.gradle.internal.resource.transport.http.HttpClientHelper.performRequest(HttpClientHelper.java:105)
	... 157 more
Caused by: java.net.SocketTimeoutException: Connect timed out
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	... 169 more
Cause 2: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
Required by:
    project :app > project :transistorsoft-capacitor-background-geolocation
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Skipped due to earlier error

==============================================================================

7: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:desugarDebugFileDependencies'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

==============================================================================

8: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:mergeDebugJavaResource'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

==============================================================================

9: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:checkDebugDuplicateClasses'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

==============================================================================

10: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not resolve com.transistorsoft:tsbackgroundfetch:+.
     Required by:
         project :app > project :transistorsoft-capacitor-background-fetch
      > Failed to list versions for com.transistorsoft:tsbackgroundfetch.
         > Unable to load Maven meta-data from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml.
            > Could not GET 'https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml'.
               > Connect to developer.huawei.com:443 [developer.huawei.com/<IP_ADDRESS>, developer.huawei.com/<IP_ADDRESS>] failed: Connect timed out
   > Could not resolve com.huawei.hms:location:<IP_ADDRESS>0.
     Required by:
         project :app > project :transistorsoft-capacitor-background-geolocation
      > Skipped due to earlier error

==============================================================================

BUILD FAILED in 3m 12s

It worked using VPN it downloads some files from https://developer.huawei.com/repo/com/transistorsoft/tsbackgroundfetch/maven-metadata.xml. use for compilation

You have a problem in your android/build.gradle.
See the Android Setup Instructions and follow them exactly.

I reinstall android studio latest version and its working now thanks.


Appropriate corpus creation for prompt type analysis

I have a set of question and answer conversations, but a few of them end with a question instead of answer, and some start with statements instead of question. For example, for one of the conversations, it end with a question, however I have checked the prompt_types__prompt_repr if this question, and apparently it has a vector representation but it should not have one right? since it does not have following answer.
Can I please check with you what would be the correct way to create a corpus of this data? Should the corpus strictly follow question->answer->question->answer... ... order?
Thanks.

There are no strict requirements on the corpus. In this particular case, the code will produce a representation for any utterance (that meets the requirements for the filter that you constructed prompt types with), even if that utterance doesn't have an answer.

Thanks @tisjune !

We derive prompt-vectors for the phrasings, which reflect similarities in the subsequent replies that a phrasing prompts.

If a prompt doesn't have a reply (or a question doesn't have an answer), then how is the prompt-reply matrix (or motif-question matrix) computed?

Think of the process as two steps: a training phase and a testing phase. In the training phase, we learn a transformation given the question-reply pairs that do exist in the data, and in the test phase we apply this transformation to every question in the data. The transformation is dependent on the question-reply pairs in the training data, but not on the actual reply that a question gets.

Aha! Actually my test data is the same as my training data. So during the training phase, the model simply ignores these questions that don't have replies. But during the test phase, the question vectors are inferred by the learnt model.


Question about beams size

In your paper, I found the following:

Beam Size k: The beam size k is set to adjust the diversity and range for HALC to search for the best candidate captions. Essentially, the global visual matching score module selects the top k diverse captions from 2m · k text sequence candidates passed from the local adaptive visual grounding module. While a larger k involves a larger search space and hopefully a better generation, the runtime cost also increases linearly with respect to k. HALC adopts Bootstrapping Language-Image Pre-training (BLIP) (Li et al., 2022a) for both text and image encoding when computing their cosine similarity scores. Notably, given the global search capability of our visual matching score module, HALC seeks to preserve a more diverse set of captions within the beam buffer.

The code also confirms that it uses beam_size = num_beams = 1 when using halc decoding method. Could you please explain how the BLIP model functions when this value is set to 1? And how does it ensure global textual fluency?

Sure, thanks for the question! Even though we set beam_size to 1 in our experiment for more efficient decoding, beam_size=1 can also be effective in searching for an optimal candidate token among the 2m tokens that we get from the bidirectional pair-wise contrasted logits. By finding the token that maximizes the image-text alignment via BLIP from the 2m candidate tokens, we can ensure global textual fluency.


[SPARK-6686][SQL] Use resolved output instead of names for toDF rename

This is a workaround for a problem reported on the user list.  This doesn't fix the core problem, but in general is a more robust way to do renames.

Test build #29629 has started for   PR 5337 at commit 6a3159d.

LGTM

Test build #29629 has finished for   PR 5337 at commit 6a3159d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29629/
Test PASSed.


Ignoring Required module not found

How do I ignore these errors?
"Required module not found" aren't useful to me.

The problem is that you are using untyped node_module dependencies.
The easiest way to bootstrap your project is to install flow-typed and do a flow-typed install :-)
This will install already typed libdef files of your dependencies in your ./flow-typed directory. If there are dependencies not tracked by flow-typed, any stubs will be created.

What if the module not being found is a "global" module in Node like process?

@CMCDragonkai that shouldn't be an issue. Flow comes with libdefs for node globals (including process). Can you provide more information to reproduce this issue?

Oh, yeah that's possible. Feel free to PR, or bump any PRs that add the definitions you need.


az resource show: CLI 2.0 command provided in "Resource Explorer" does not work

Describe the bug
When I cut'n paste the Azure CLI v2.0 command from https://resources.azure.com/subscriptions I get:
$ az resource show --id /subscriptions/deadbeaf-1111-2222-3333-666666666666/resources --api-version 2017-05-10
az resource: error: argument --ids: invalid ResourceId value: '/subscriptions/deadbeef-1111-2222-3333-666666666666/resources'
To Reproduce
Login to https://resources.azure.com/
Under subscriptions click on resources
Cut'n paste the command from the Azure CLI v2.0 tab
Expected behavior
I expect to receive the same json as in data tab of https://resources.azure.com
Environment summary
rpm fedora 28 install:
# rpm -qf /bin/az
azure-cli-2.0.33-1.el7.x86_64

The ID in that example is fictitious. There is no value that can be put there that is "cut and paste"-able. You would need to supply your own ID for some Azure resource.

It did not seem like a good idea to me to post the real ID to a public forum. Did you actually try to reproduce it?

Sorry, I misunderstood the issue. I thought you cut and paste an example by running az resource show -h which most often can't be simply pasted in.

The question would be whether that ID (which is rejected by msrestazure as invalid) is accepted by the REST API or whether resource explorer is interpreting it and doing some "extra stuff".  If it's the former, then we should definitely fix the ID parsing in msrestazure to support the scenario.  If the latter, then we would have to decide whether to copy the feature or not.

No worries, I guess I could have been clearer. Are you able to reproduce this?

Yes, I can reproduce the behavior and have confirmed that the REST API supports this ID.  We'll have to fix the issue in msrestazure that is blocking this.  There may be an additional fix in the CLI. Thanks for the report!

@yugangw-msft another alternative would be to simply detect this special-case ID type and not put it through the parser.  What do you think?  The format is:
/subscriptions/{subscription-id}[/resourceGroups/{rg}]/resources

@tjprescott , agreed we can detect this case. After that, shall we error out, or redirect to ResourcesOperations.list_by_resource_group?

Not sure if it helps, but powershell has the same issue in the latest AzureRM (6.1.1). This was working in 5.5.0.

The same would happen if one tried to do a resource show on /subscriptions/00977cdb-163f-435f-9c32-00000000000/providers/Microsoft.Storage/storageAccounts
While this and /subscriptions/deadbeaf-1111-2222-3333-666666666666/resources are valid ARM IDs, they do not refer to specific ARM resources.

I would argue we not error out, but simply detect these special-case IDs and pass them along. I think it would be too much work to try and "redirect" the user to different commands. It seems that there is (potentially) some additional metadata that the resource show command might expose that the corresponding list command does not.

We would need to fix this in msrest, imo, if this form of ID was accepted anywhere an ARM ID could be supplied. I doubt that this is the case. If it is only interpreted by the ARM resource endpoints, then I believe we should just adjust the custom command in the CLI.

Even the resource sdk docs expect a id to be given for a specific ARM resource:
https://github.com/Azure/azure-sdk-for-python/blob/master/azure-mgmt-resource/azure/mgmt/resource/resources/v2018_02_01/operations/resources_operations.py#L1222
Anything other than a ARM resource id should be unknown territory.

@tjprescott @yugangw-msft, what is our consensus on this? Do we want to permit this type of ID or not?

I would say no. The Azure CLI script tab was removed because the scripts in it were not actually verified to work. The resource explorer cannot make statements about what the CLI command should do, but should instead rely on what the CLI does. Since the type of ID does not work in the CLI, it should never have appeared in the Resource Explorer. I would recommend closing this.

Thanks @tjprescott. This all makes sense.
I will close this issue


New regions

Issue #, if available:
Description of changes:
Make the regional tests work for the new regions.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


rust cli: Rename to nmstatectl-rust

The previous name is already taken by project http://www.ncl.ucar.edu/ ,
hence rename to nmstate-rust

I have rebased it myself, I hope this is fine for you :-)


[QUESTION] Ho to run hyperf command at runtime ?

How to run FreshCommand at runtime ?

Suppose there is a FooCommand.。
#[Command]
class FooCommand extends HyperfCommand
{
    protected ?string $name = 'foo';

    public function handle()
    {
        $this->line('Here is FooCommand!', 'info');
    }
}

You can execute the command at runtime with the following code.
$command = ApplicationContext::getContainer()
        ->get(Hyperf\Contract\ApplicationInterface::class)
        ->find('foo');

$arguments = [];
$command->run(new ArrayInput($arguments), new ConsoleOutput());

References：How to Call a Command from a Controller


Add a dependency for mailhog, but leave it disabled by default.

Description
Adds a dependency on mailhog, that is disabled by default.
I have another PR in acp-on-k8s to use mailhog for email.
Information for QA

[ ] Is QA testing required?
[ ] Does PR contain unit tests?
[ ] Should QA create E2E tests for the change?

Are You sure we want to ship ACP with mailhog dependency by default? Shouldn't this be something separate from charts?

That is a good point. This may not be a good idea. We also have the problem, that this branch does not even accomplish the basic goal. ACP emails are not being sent to Mailhog.  I am going to change this PR to draft status.


Issues with initialising the storage/conversion nodes for the present year

When we calculate storage and conversion, we need to run Merit on the demand curve and, hour by hour, determine the amount of energy that is stored/converted.
This is relatively 'straightforward' for the future year, but for the present things are not so easy. Especially, I am worried about how to initialise the graph.
The problem is that we don't know which numbers to use for the initialisation of the graph. This is done by the analysis on etdataset and the resulting shares and preset demands on etsource. To be able to calculate the preset demands and shares, we would need to perform the whole 'Merit-storage-calculation' in the dataset analysis Excel. Worse than the InputExcel IMHO!
What if we assume the storage/conversion to be zero for the present year?
This is the most obvious approach but it has some drawbacks:

We will not be able to handle start-years and countries for which the storage/conversion is non-zero in the present year. Currently, there are no such countries and start-years but that will rapidly change (hopefully).

Including @dennisschoenmakers @AlexanderWirtz @jorisberkhout @antw

Good point @ChaelKruip. I think this is the least bad solution. I agree that making the research analyses more complicated is not desirable. Still, you may not need to make them that complicated in order to obtain something that can initialize the graph.

This is still very relevant, but not deploy-critical as all flexibility related demands are currently zero in the start year. I will remove the milestone and assign myself.


http2 to external upstream fails

Description
I'm attempting to setup an envoy that provides egress to an HTTP2 enabled server and consistently see 503 responses saying connection terminated. Switching to HTTP/1.1 on the upstream works just fine. I've simplified my configuration to use an example server, but any h2 server seems to behave the same.
I'm new to envoy, so I'm sure I'm doing something wrong here, but I've tried every combination of configuration I can think of. Any help would be appreciated. Thanks!
Repro steps

save config below as envoy.yaml

see successful request via HTTP/1.1 to upstream

[term 1]
$ docker run -it -p 8080:8080 --mount "type=bind,source=$(pwd)/envoy.yaml,target=/etc/envoy/envoy.yaml" envoyproxy/envoy:v1.11.0 -c /etc/envoy/envoy.yaml -l trace`

[term 2]
$ curl -v http://localhost:8080/reqinfo
HTTP/1.1 200 OK
[... rest of successful response ...]

uncomment http2_protocol_options in config and restart docker instance

$ curl -i http://localhost:8080/reqinfo
HTTP/1.1 503 Service Unavailable
content-length: 95
content-type: text/plain
date: Wed, 14 Aug 2019 20:57:18 GMT
server: envoy

upstream connect error or disconnect/reset before headers. reset reason: connection termination

Config
  listeners:
  - address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match:
                  prefix: /
                route:
                  cluster: upstream
                  auto_host_rewrite: true
          http_filters:
          - name: envoy.router
  clusters:
  - name: upstream
    connect_timeout: 1s
    type: strict_dns
    lb_policy: round_robin
    # http2_protocol_options: {} ## UNCOMMENT ME FOR TROUBLE
    respect_dns_ttl: true
    tls_context:
      sni: http2.golang.org
    load_assignment:
      cluster_name: upstream
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: http2.golang.org
                port_value: 443
                protocol: TCP

Logs
[2019-08-14 20:57:16.290][1][info][main] [source/server/server.cc:238] initializing epoch 0 (hot restart version=11.104)
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:240] statically linked extensions:
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:242]   access_loggers: envoy.file_access_log,envoy.http_grpc_access_log
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:245]   filters.http: envoy.buffer,envoy.cors,envoy.csrf,envoy.ext_authz,envoy.fault,envoy.filters.http.dynamic_forward_proxy,envoy.filters.http.grpc_http1_reverse_bridge,envoy.filters.http.header_to_metadata,envoy.filters.http.jwt_authn,envoy.filters.http.original_src,envoy.filters.http.rbac,envoy.filters.http.tap,envoy.grpc_http1_bridge,envoy.grpc_json_transcoder,envoy.grpc_web,envoy.gzip,envoy.health_check,envoy.http_dynamo_filter,envoy.ip_tagging,envoy.lua,envoy.rate_limit,envoy.router,envoy.squash
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:248]   filters.listener: envoy.listener.original_dst,envoy.listener.original_src,envoy.listener.proxy_protocol,envoy.listener.tls_inspector
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:251]   filters.network: envoy.client_ssl_auth,envoy.echo,envoy.ext_authz,envoy.filters.network.dubbo_proxy,envoy.filters.network.mysql_proxy,envoy.filters.network.rbac,envoy.filters.network.sni_cluster,envoy.filters.network.thrift_proxy,envoy.filters.network.zookeeper_proxy,envoy.http_connection_manager,envoy.mongo_proxy,envoy.ratelimit,envoy.redis_proxy,envoy.tcp_proxy
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:253]   stat_sinks: envoy.dog_statsd,envoy.metrics_service,envoy.stat_sinks.hystrix,envoy.statsd
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:255]   tracers: envoy.dynamic.ot,envoy.lightstep,envoy.tracers.datadog,envoy.tracers.opencensus,envoy.zipkin
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:258]   transport_sockets.downstream: envoy.transport_sockets.alts,envoy.transport_sockets.tap,raw_buffer,tls
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:261]   transport_sockets.upstream: envoy.transport_sockets.alts,envoy.transport_sockets.tap,raw_buffer,tls
[2019-08-14 20:57:16.291][1][info][main] [source/server/server.cc:267] buffer implementation: old (libevent)
[2019-08-14 20:57:16.304][1][warning][main] [source/server/server.cc:327] No admin address given, so no admin HTTP server started.
[2019-08-14 20:57:16.304][1][debug][main] [source/server/overload_manager_impl.cc:173] No overload action is configured for envoy.overload_actions.shrink_heap.
[2019-08-14 20:57:16.304][1][debug][main] [source/server/overload_manager_impl.cc:173] No overload action is configured for envoy.overload_actions.stop_accepting_connections.
[2019-08-14 20:57:16.304][1][debug][main] [source/server/overload_manager_impl.cc:173] No overload action is configured for envoy.overload_actions.stop_accepting_connections.
[2019-08-14 20:57:16.304][1][debug][main] [source/server/overload_manager_impl.cc:173] No overload action is configured for envoy.overload_actions.stop_accepting_connections.
[2019-08-14 20:57:16.304][1][debug][main] [source/server/overload_manager_impl.cc:173] No overload action is configured for envoy.overload_actions.stop_accepting_connections.
[2019-08-14 20:57:16.305][1][info][main] [source/server/server.cc:432] runtime: layers:
  - name: base
    static_layer:
      {}
  - name: admin
    admin_layer:
      {}
[2019-08-14 20:57:16.305][1][warning][runtime] [source/common/runtime/runtime_impl.cc:485] Skipping unsupported runtime layer: name: "base"
static_layer {
}

[2019-08-14 20:57:16.305][1][info][config] [source/server/configuration_impl.cc:61] loading 0 static secret(s)
[2019-08-14 20:57:16.305][1][info][config] [source/server/configuration_impl.cc:67] loading 1 cluster(s)
[2019-08-14 20:57:16.305][9][debug][grpc] [source/common/grpc/google_async_client_impl.cc:43] completionThread running
[2019-08-14 20:57:16.306][1][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:839] adding TLS initial cluster upstream
[2019-08-14 20:57:16.307][1][trace][upstream] [source/common/upstream/strict_dns_cluster.cc:89] starting async DNS resolution for http2.golang.org
[2019-08-14 20:57:16.307][1][trace][upstream] [source/common/network/dns_impl.cc:160] Setting DNS resolution timer for 5000 milliseconds
[2019-08-14 20:57:16.307][1][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:75] cm init: adding: cluster=upstream primary=1 secondary=0
[2019-08-14 20:57:16.307][1][info][config] [source/server/configuration_impl.cc:71] loading 1 listener(s)
[2019-08-14 20:57:16.307][1][debug][config] [source/server/configuration_impl.cc:73] listener #0:
[2019-08-14 20:57:16.307][1][debug][config] [source/server/listener_manager_impl.cc:485] begin add/update listener: name=c17fb16f-0576-4d4c-a3b3-e159ac47a836 hash=3421765951345632697
[2019-08-14 20:57:16.308][1][debug][config] [source/server/listener_manager_impl.cc:57]   filter #0:
[2019-08-14 20:57:16.308][1][debug][config] [source/server/listener_manager_impl.cc:58]     name: envoy.http_connection_manager
[2019-08-14 20:57:16.308][1][debug][config] [source/server/listener_manager_impl.cc:61]   config: {"route_config":{"virtual_hosts":[{"name":"backend","routes":[{"match":{"prefix":"/"},"route":{"auto_host_rewrite":true,"cluster":"upstream"}}],"domains":["*"]}],"name":"local_route"},"http_filters":[{"name":"envoy.router"}],"stat_prefix":"ingress_http"}
[2019-08-14 20:57:16.310][1][debug][config] [source/extensions/filters/network/http_connection_manager/config.cc:340]     http filter #0
[2019-08-14 20:57:16.310][1][debug][config] [source/extensions/filters/network/http_connection_manager/config.cc:341]       name: envoy.router
[2019-08-14 20:57:16.310][1][debug][config] [source/extensions/filters/network/http_connection_manager/config.cc:345]     config: {}
[2019-08-14 20:57:16.310][1][debug][config] [source/server/listener_manager_impl.cc:376] add active listener: name=c17fb16f-0576-4d4c-a3b3-e159ac47a836, hash=3421765951345632697, address=<IP_ADDRESS>:8080
[2019-08-14 20:57:16.310][1][info][config] [source/server/configuration_impl.cc:96] loading tracing configuration
[2019-08-14 20:57:16.310][1][info][config] [source/server/configuration_impl.cc:116] loading stats sink configuration
[2019-08-14 20:57:16.311][1][info][main] [source/server/server.cc:516] starting main dispatch loop
[2019-08-14 20:57:16.327][1][trace][upstream] [source/common/network/dns_impl.cc:160] Setting DNS resolution timer for 5000 milliseconds
[2019-08-14 20:57:16.329][1][trace][upstream] [source/common/upstream/strict_dns_cluster.cc:96] async DNS resolution complete for http2.golang.org
[2019-08-14 20:57:16.329][1][debug][upstream] [source/common/upstream/strict_dns_cluster.cc:122] DNS hosts have changed for http2.golang.org
[2019-08-14 20:57:16.329][1][trace][upstream] [source/common/upstream/upstream_impl.cc:1001] Local locality:
[2019-08-14 20:57:16.329][1][debug][upstream] [source/common/upstream/upstream_impl.cc:773] initializing secondary cluster upstream completed
[2019-08-14 20:57:16.329][1][debug][init] [source/common/init/manager_impl.cc:45] init manager Cluster upstream contains no targets
[2019-08-14 20:57:16.329][1][debug][init] [source/common/init/watcher_impl.cc:14] init manager Cluster upstream initialized, notifying ClusterImplBase
[2019-08-14 20:57:16.329][1][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:999] membership update for TLS cluster upstream added 1 removed 0
[2019-08-14 20:57:16.329][1][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:103] cm init: init complete: cluster=upstream primary=0 secondary=0
[2019-08-14 20:57:16.329][1][info][upstream] [source/common/upstream/cluster_manager_impl.cc:148] cm init: all clusters initialized
[2019-08-14 20:57:16.329][1][info][main] [source/server/server.cc:500] all clusters initialized. initializing init manager
[2019-08-14 20:57:16.329][1][debug][init] [source/common/init/manager_impl.cc:45] init manager Server contains no targets
[2019-08-14 20:57:16.329][1][debug][init] [source/common/init/watcher_impl.cc:14] init manager Server initialized, notifying RunHelper
[2019-08-14 20:57:16.329][1][info][config] [source/server/listener_manager_impl.cc:761] all dependencies initialized. starting workers
[2019-08-14 20:57:16.330][11][debug][main] [source/server/worker_impl.cc:101] worker entering dispatch loop
[2019-08-14 20:57:16.330][12][debug][main] [source/server/worker_impl.cc:101] worker entering dispatch loop
[2019-08-14 20:57:16.330][13][debug][main] [source/server/worker_impl.cc:101] worker entering dispatch loop
[2019-08-14 20:57:16.331][11][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:839] adding TLS initial cluster upstream
[2019-08-14 20:57:16.331][14][debug][grpc] [source/common/grpc/google_async_client_impl.cc:43] completionThread running
[2019-08-14 20:57:16.331][15][debug][main] [source/server/worker_impl.cc:101] worker entering dispatch loop
[2019-08-14 20:57:16.331][1][debug][upstream] [source/common/upstream/strict_dns_cluster.cc:144] DNS refresh rate reset for http2.golang.org, refresh rate 4502000 ms
[2019-08-14 20:57:16.331][11][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:999] membership update for TLS cluster upstream added 1 removed 0
[2019-08-14 20:57:16.331][12][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:839] adding TLS initial cluster upstream
[2019-08-14 20:57:16.331][16][debug][grpc] [source/common/grpc/google_async_client_impl.cc:43] completionThread running
[2019-08-14 20:57:16.332][15][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:839] adding TLS initial cluster upstream
[2019-08-14 20:57:16.332][17][debug][grpc] [source/common/grpc/google_async_client_impl.cc:43] completionThread running
[2019-08-14 20:57:16.332][12][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:999] membership update for TLS cluster upstream added 1 removed 0
[2019-08-14 20:57:16.333][15][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:999] membership update for TLS cluster upstream added 1 removed 0
[2019-08-14 20:57:16.333][13][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:839] adding TLS initial cluster upstream
[2019-08-14 20:57:16.333][13][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:999] membership update for TLS cluster upstream added 1 removed 0
[2019-08-14 20:57:16.333][18][debug][grpc] [source/common/grpc/google_async_client_impl.cc:43] completionThread running
[2019-08-14 20:57:18.471][15][debug][main] [source/server/connection_handler_impl.cc:280] [C0] new connection
[2019-08-14 20:57:18.471][15][trace][connection] [source/common/network/connection_impl.cc:456] [C0] socket event: 2
[2019-08-14 20:57:18.471][15][trace][connection] [source/common/network/connection_impl.cc:541] [C0] write ready
[2019-08-14 20:57:18.471][15][trace][connection] [source/common/network/connection_impl.cc:456] [C0] socket event: 3
[2019-08-14 20:57:18.471][15][trace][connection] [source/common/network/connection_impl.cc:541] [C0] write ready
[2019-08-14 20:57:18.471][15][trace][connection] [source/common/network/connection_impl.cc:494] [C0] read ready
[2019-08-14 20:57:18.472][15][trace][connection] [source/common/network/raw_buffer_socket.cc:23] [C0] read returns: 85
[2019-08-14 20:57:18.472][15][trace][connection] [source/common/network/raw_buffer_socket.cc:37] [C0] read error: Resource temporarily unavailable
[2019-08-14 20:57:18.472][15][trace][http] [source/common/http/http1/codec_impl.cc:366] [C0] parsing 85 bytes
[2019-08-14 20:57:18.472][15][trace][http] [source/common/http/http1/codec_impl.cc:479] [C0] message begin
[2019-08-14 20:57:18.472][15][debug][http] [source/common/http/conn_manager_impl.cc:246] [C0] new stream
[2019-08-14 20:57:18.472][15][trace][http] [source/common/http/http1/codec_impl.cc:334] [C0] completed header: key=Host value=localhost:8080
[2019-08-14 20:57:18.473][15][trace][http] [source/common/http/http1/codec_impl.cc:334] [C0] completed header: key=User-Agent value=curl/7.54.0
[2019-08-14 20:57:18.473][15][trace][http] [source/common/http/http1/codec_impl.cc:445] [C0] headers complete
[2019-08-14 20:57:18.473][15][trace][http] [source/common/http/http1/codec_impl.cc:334] [C0] completed header: key=Accept value=*/*
[2019-08-14 20:57:18.473][15][trace][http] [source/common/http/http1/codec_impl.cc:466] [C0] message complete
[2019-08-14 20:57:18.473][15][debug][http] [source/common/http/conn_manager_impl.cc:600] [C0][S3890394461460335529] request headers complete (end_stream=true):
':authority', 'localhost:8080'
':path', '/reqinfo'
':method', 'GET'
'user-agent', 'curl/7.54.0'
'accept', '*/*'

[2019-08-14 20:57:18.473][15][debug][http] [source/common/http/conn_manager_impl.cc:1092] [C0][S3890394461460335529] request end stream
[2019-08-14 20:57:18.474][15][debug][router] [source/common/router/router.cc:401] [C0][S3890394461460335529] cluster 'upstream' match for URL '/reqinfo'
[2019-08-14 20:57:18.474][15][debug][router] [source/common/router/router.cc:514] [C0][S3890394461460335529] router decoding headers:
':authority', 'localhost:8080'
':path', '/reqinfo'
':method', 'GET'
':scheme', 'https'
'user-agent', 'curl/7.54.0'
'accept', '*/*'
'x-forwarded-proto', 'http'
'x-request-id', '515e2ccc-4617-4fce-9d9d-4418921606f4'
'x-envoy-expected-rq-timeout-ms', '15000'

[2019-08-14 20:57:18.474][15][debug][client] [source/common/http/codec_client.cc:26] [C1] connecting
[2019-08-14 20:57:18.474][15][debug][connection] [source/common/network/connection_impl.cc:702] [C1] connecting to <IP_ADDRESS>:443
[2019-08-14 20:57:18.474][15][debug][connection] [source/common/network/connection_impl.cc:711] [C1] connection in progress
[2019-08-14 20:57:18.475][15][debug][http2] [source/common/http/http2/codec_impl.cc:726] [C1] setting stream-level initial window size to 268435456
[2019-08-14 20:57:18.475][15][debug][http2] [source/common/http/http2/codec_impl.cc:748] [C1] updating connection-level initial window size to 268435456
[2019-08-14 20:57:18.475][15][debug][pool] [source/common/http/conn_pool_base.cc:20] queueing request due to no available connections
[2019-08-14 20:57:18.475][15][trace][http] [source/common/http/conn_manager_impl.cc:857] [C0][S3890394461460335529] decode headers called: filter=0x24aa730 status=1
[2019-08-14 20:57:18.475][15][trace][http] [source/common/http/http1/codec_impl.cc:387] [C0] parsed 85 bytes
[2019-08-14 20:57:18.475][15][trace][connection] [source/common/network/connection_impl.cc:288] [C0] readDisable: enabled=true disable=true
[2019-08-14 20:57:18.475][15][trace][connection] [source/common/network/connection_impl.cc:456] [C0] socket event: 2
[2019-08-14 20:57:18.475][15][trace][connection] [source/common/network/connection_impl.cc:541] [C0] write ready
[2019-08-14 20:57:18.524][15][trace][connection] [source/common/network/connection_impl.cc:456] [C1] socket event: 2
[2019-08-14 20:57:18.524][15][trace][connection] [source/common/network/connection_impl.cc:541] [C1] write ready
[2019-08-14 20:57:18.524][15][debug][connection] [source/common/network/connection_impl.cc:550] [C1] connected
[2019-08-14 20:57:18.524][15][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C1] handshake error: 2
[2019-08-14 20:57:18.572][15][trace][connection] [source/common/network/connection_impl.cc:456] [C1] socket event: 3
[2019-08-14 20:57:18.572][15][trace][connection] [source/common/network/connection_impl.cc:541] [C1] write ready
[2019-08-14 20:57:18.574][15][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C1] handshake error: 2
[2019-08-14 20:57:18.574][15][trace][connection] [source/common/network/connection_impl.cc:494] [C1] read ready
[2019-08-14 20:57:18.574][15][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C1] handshake error: 2
[2019-08-14 20:57:18.622][15][trace][connection] [source/common/network/connection_impl.cc:456] [C1] socket event: 3
[2019-08-14 20:57:18.622][15][trace][connection] [source/common/network/connection_impl.cc:541] [C1] write ready
[2019-08-14 20:57:18.622][15][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:157] [C1] handshake complete
[2019-08-14 20:57:18.623][15][debug][client] [source/common/http/codec_client.cc:64] [C1] connected
[2019-08-14 20:57:18.623][15][debug][pool] [source/common/http/http2/conn_pool.cc:96] [C1] creating stream
[2019-08-14 20:57:18.623][15][debug][router] [source/common/router/router.cc:1503] [C0][S3890394461460335529] pool ready
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:559] [C1] send data: bytes=24
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:392] [C1] writing 24 bytes, end_stream false
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:559] [C1] send data: bytes=21
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:392] [C1] writing 21 bytes, end_stream false
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:511] [C1] sent frame type=4
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:559] [C1] send data: bytes=13
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:392] [C1] writing 13 bytes, end_stream false
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:511] [C1] sent frame type=8
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:559] [C1] send data: bytes=134
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:392] [C1] writing 134 bytes, end_stream false
[2019-08-14 20:57:18.623][15][trace][http2] [source/common/http/http2/codec_impl.cc:511] [C1] sent frame type=1
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:541] [C1] write ready
[2019-08-14 20:57:18.623][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:234] [C1] ssl write returns: 192
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:494] [C1] read ready
[2019-08-14 20:57:18.623][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:73] [C1] ssl read returns: -1
[2019-08-14 20:57:18.623][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:148] [C1] ssl read 0 bytes into 0 slices
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:456] [C1] socket event: 2
[2019-08-14 20:57:18.623][15][trace][connection] [source/common/network/connection_impl.cc:541] [C1] write ready
[2019-08-14 20:57:18.671][15][trace][connection] [source/common/network/connection_impl.cc:456] [C1] socket event: 3
[2019-08-14 20:57:18.672][15][trace][connection] [source/common/network/connection_impl.cc:541] [C1] write ready
[2019-08-14 20:57:18.672][15][trace][connection] [source/common/network/connection_impl.cc:494] [C1] read ready
[2019-08-14 20:57:18.672][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:73] [C1] ssl read returns: 103
[2019-08-14 20:57:18.672][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:73] [C1] ssl read returns: 0
[2019-08-14 20:57:18.672][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:148] [C1] ssl read 103 bytes into 1 slices
[2019-08-14 20:57:18.672][15][trace][http2] [source/common/http/http2/codec_impl.cc:343] [C1] dispatching 103 bytes
[2019-08-14 20:57:18.672][15][trace][http2] [source/common/http/http2/codec_impl.cc:358] [C1] dispatched 103 bytes
[2019-08-14 20:57:18.672][15][trace][http2] [source/common/http/http2/codec_impl.cc:559] [C1] send data: bytes=34
[2019-08-14 20:57:18.672][15][trace][connection] [source/common/network/connection_impl.cc:392] [C1] writing 34 bytes, end_stream false
[2019-08-14 20:57:18.672][15][trace][http2] [source/common/http/http2/codec_impl.cc:511] [C1] sent frame type=7
[2019-08-14 20:57:18.672][15][debug][http2] [source/common/http/http2/codec_impl.cc:514] [C1] sent goaway code=1
[2019-08-14 20:57:18.672][15][debug][client] [source/common/http/codec_client.cc:118] [C1] protocol error: The user callback function failed
[2019-08-14 20:57:18.672][15][debug][connection] [source/common/network/connection_impl.cc:101] [C1] closing data_to_write=34 type=1
[2019-08-14 20:57:18.672][15][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:234] [C1] ssl write returns: 34
[2019-08-14 20:57:18.672][15][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:270] [C1] SSL shutdown: rc=1
[2019-08-14 20:57:18.672][15][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:201] [C1]
[2019-08-14 20:57:18.672][15][debug][connection] [source/common/network/connection_impl.cc:188] [C1] closing socket: 1
[2019-08-14 20:57:18.672][15][debug][client] [source/common/http/codec_client.cc:82] [C1] disconnect. resetting 1 pending requests
[2019-08-14 20:57:18.673][15][debug][client] [source/common/http/codec_client.cc:105] [C1] request reset
[2019-08-14 20:57:18.673][15][trace][main] [source/common/event/dispatcher_impl.cc:158] item added to deferred deletion list (size=1)
[2019-08-14 20:57:18.673][15][debug][pool] [source/common/http/http2/conn_pool.cc:233] [C1] destroying stream: 0 remaining
[2019-08-14 20:57:18.673][15][debug][router] [source/common/router/router.cc:868] [C0][S3890394461460335529] upstream reset: reset reason connection termination
[2019-08-14 20:57:18.673][15][debug][http] [source/common/http/conn_manager_impl.cc:1167] [C0][S3890394461460335529] Sending local reply with details upstream_reset_before_response_started{connection termination}
[2019-08-14 20:57:18.673][15][debug][http] [source/common/http/conn_manager_impl.cc:1359] [C0][S3890394461460335529] encoding headers via codec (end_stream=false):
':status', '503'
'content-length', '95'
'content-type', 'text/plain'
'date', 'Wed, 14 Aug 2019 20:57:18 GMT'
'server', 'envoy'

[2019-08-14 20:57:18.673][15][trace][connection] [source/common/network/connection_impl.cc:392] [C0] writing 134 bytes, end_stream false
[2019-08-14 20:57:18.673][15][trace][http] [source/common/http/conn_manager_impl.cc:1497] [C0][S3890394461460335529] encoding data via codec (size=95 end_stream=true)
[2019-08-14 20:57:18.673][15][trace][connection] [source/common/network/connection_impl.cc:392] [C0] writing 95 bytes, end_stream false
[2019-08-14 20:57:18.673][15][trace][main] [source/common/event/dispatcher_impl.cc:158] item added to deferred deletion list (size=2)
[2019-08-14 20:57:18.673][15][trace][connection] [source/common/network/connection_impl.cc:288] [C0] readDisable: enabled=false disable=false
[2019-08-14 20:57:18.673][15][debug][pool] [source/common/http/http2/conn_pool.cc:149] [C1] client disconnected
[2019-08-14 20:57:18.673][15][debug][pool] [source/common/http/http2/conn_pool.cc:171] [C1] destroying primary client
[2019-08-14 20:57:18.673][15][trace][main] [source/common/event/dispatcher_impl.cc:158] item added to deferred deletion list (size=3)
[2019-08-14 20:57:18.673][15][debug][connection] [source/common/network/connection_impl.cc:518] [C1] remote close
[2019-08-14 20:57:18.673][15][trace][main] [source/common/event/dispatcher_impl.cc:76] clearing deferred deletion list (size=3)
[2019-08-14 20:57:18.673][15][trace][connection] [source/common/network/connection_impl.cc:456] [C0] socket event: 2
[2019-08-14 20:57:18.673][15][trace][connection] [source/common/network/connection_impl.cc:541] [C0] write ready
[2019-08-14 20:57:18.673][15][trace][connection] [source/common/network/raw_buffer_socket.cc:66] [C0] write returns: 229
[2019-08-14 20:57:18.675][15][trace][connection] [source/common/network/connection_impl.cc:456] [C0] socket event: 3
[2019-08-14 20:57:18.675][15][trace][connection] [source/common/network/connection_impl.cc:541] [C0] write ready
[2019-08-14 20:57:18.675][15][trace][connection] [source/common/network/connection_impl.cc:494] [C0] read ready
[2019-08-14 20:57:18.675][15][trace][connection] [source/common/network/raw_buffer_socket.cc:23] [C0] read returns: 0
[2019-08-14 20:57:18.675][15][debug][connection] [source/common/network/connection_impl.cc:518] [C0] remote close
[2019-08-14 20:57:18.675][15][debug][connection] [source/common/network/connection_impl.cc:188] [C0] closing socket: 0
[2019-08-14 20:57:18.675][15][debug][main] [source/server/connection_handler_impl.cc:80] [C0] adding to cleanup list
[2019-08-14 20:57:18.675][15][trace][main] [source/common/event/dispatcher_impl.cc:158] item added to deferred deletion list (size=1)
[2019-08-14 20:57:18.675][15][trace][main] [source/common/event/dispatcher_impl.cc:76] clearing deferred deletion list (size=1)
^C[2019-08-14 20:57:20.419][1][warning][main] [source/server/server.cc:468] caught SIGINT
[2019-08-14 20:57:20.419][1][info][main] [source/server/server.cc:567] shutting down server instance
[2019-08-14 20:57:20.419][1][info][main] [source/server/server.cc:521] main dispatch loop exited
[2019-08-14 20:57:20.419][11][debug][main] [source/server/worker_impl.cc:105] worker exited dispatch loop
[2019-08-14 20:57:20.419][11][debug][grpc] [source/common/grpc/google_async_client_impl.cc:33] Joining completionThread
[2019-08-14 20:57:20.419][14][debug][grpc] [source/common/grpc/google_async_client_impl.cc:66] completionThread exiting
[2019-08-14 20:57:20.419][11][debug][grpc] [source/common/grpc/google_async_client_impl.cc:35] Joined completionThread
[2019-08-14 20:57:20.419][11][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:851] shutting down thread local cluster manager
[2019-08-14 20:57:20.420][12][debug][main] [source/server/worker_impl.cc:105] worker exited dispatch loop
[2019-08-14 20:57:20.420][12][debug][grpc] [source/common/grpc/google_async_client_impl.cc:33] Joining completionThread
[2019-08-14 20:57:20.420][16][debug][grpc] [source/common/grpc/google_async_client_impl.cc:66] completionThread exiting
[2019-08-14 20:57:20.420][12][debug][grpc] [source/common/grpc/google_async_client_impl.cc:35] Joined completionThread
[2019-08-14 20:57:20.420][12][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:851] shutting down thread local cluster manager
[2019-08-14 20:57:20.420][13][debug][main] [source/server/worker_impl.cc:105] worker exited dispatch loop
[2019-08-14 20:57:20.420][13][debug][grpc] [source/common/grpc/google_async_client_impl.cc:33] Joining completionThread
[2019-08-14 20:57:20.420][18][debug][grpc] [source/common/grpc/google_async_client_impl.cc:66] completionThread exiting
[2019-08-14 20:57:20.420][13][debug][grpc] [source/common/grpc/google_async_client_impl.cc:35] Joined completionThread
[2019-08-14 20:57:20.420][13][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:851] shutting down thread local cluster manager
[2019-08-14 20:57:20.420][15][debug][main] [source/server/worker_impl.cc:105] worker exited dispatch loop
[2019-08-14 20:57:20.421][17][debug][grpc] [source/common/grpc/google_async_client_impl.cc:66] completionThread exiting
[2019-08-14 20:57:20.421][15][debug][grpc] [source/common/grpc/google_async_client_impl.cc:33] Joining completionThread
[2019-08-14 20:57:20.421][15][debug][grpc] [source/common/grpc/google_async_client_impl.cc:35] Joined completionThread
[2019-08-14 20:57:20.421][15][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:851] shutting down thread local cluster manager
[2019-08-14 20:57:20.421][1][debug][main] [source/server/server.cc:170] flushing stats
[2019-08-14 20:57:20.421][1][debug][init] [source/common/init/watcher_impl.cc:27] ClusterImplBase destroyed
[2019-08-14 20:57:20.421][1][debug][init] [source/common/init/watcher_impl.cc:27] init manager Cluster upstream destroyed
[2019-08-14 20:57:20.421][1][debug][grpc] [source/common/grpc/google_async_client_impl.cc:33] Joining completionThread
[2019-08-14 20:57:20.421][9][debug][grpc] [source/common/grpc/google_async_client_impl.cc:66] completionThread exiting
[2019-08-14 20:57:20.422][1][debug][grpc] [source/common/grpc/google_async_client_impl.cc:35] Joined completionThread
[2019-08-14 20:57:20.422][1][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:851] shutting down thread local cluster manager
[2019-08-14 20:57:20.422][1][info][main] [source/server/server.cc:560] exiting
[2019-08-14 20:57:20.422][1][debug][init] [source/common/init/watcher_impl.cc:27] RunHelper destroyed
[2019-08-14 20:57:20.422][1][debug][init] [source/common/init/watcher_impl.cc:27] ListenerImpl destroyed
[2019-08-14 20:57:20.422][1][debug][init] [source/common/init/watcher_impl.cc:27] init manager Listener c17fb16f-0576-4d4c-a3b3-e159ac47a836 destroyed
[2019-08-14 20:57:20.423][1][debug][init] [source/common/init/watcher_impl.cc:27] init manager Server destroyed

Try setting alpn_protocols to h2
https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto#auth-commontlscontext in your cluster tls_context?

Gah! I really thought I had tried that, but it does in fact seem to do the trick. Thank you!!

Gah! I really thought I had tried that, but it does in fact seem to do the trick. Thank you!!

can you share your last changes on this issue


adding chef_data_bag_item method to load cheffish

Thanks for this PR, as it turns out there was another PR to fix this one and for various reasons we took that one.


Tracking issue for javascript bundler integration

This is a point of coordination for work that JS bundlers are doing along two fronts:

Consuming npm packages with .wasm binaries.
Allowing for direct use of Rust source.

The former is connected to our npm integration story, but will probably not be Rust-specific, since the npm packages will likely just contain a compiled .wasm blob.

Webpack 4.0 beta supports wasm modules natively, and the README of wasm-bindgen was rewritten to exercise this like hello_world example

I'm gonna close this since webpack works quite well nowadays!


tooltips: Make size of tooltips consistent.

CZO discussion

Fixes:

Screenshots and screen captures:

Before
After

CZO discussion

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[x] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

@roanster007 can you review this?

LGTM!

Based on the CZO discussion, it sounds like we need a different approach.

Updated the PR to change font-size of tooltips in tooltips.css.

This strategy looks right to me, merged, thanks @Vector73!


How to define "AIRFLOW__CORE__FERNET_KEY" in airflow variable?

I am running into issues when airflow ecs fargate container restarts and lose all my connections.
I need to declare AIRFLOW__CORE__FERNET_KEY in the variable, how do I define that.
Here is the link to my problem - https://qiita.com/ctivan/items/068a26fc6ba25110a87a

This is already allowed in the module and can be declared as follows.
airflow_variables = {
AIRFLOW__CORE__FERNET_KEY : "12345678"
}


F&F:Need the images from contact.

Need the images from contacts.

-Showing wrong image.Tested on Dev app version 1.3.2(170)

Lets test for avatar image.
This one is for F&F with no avatar image.

I think this issue and https://github.com/bithyve/hexa/issues/1457 both require us to refactor the code so there's more clarity around how images are being fetched, stored, and read out for contacts. Right now, we're already trying a myriad of guesses and fallbacks, but I'd like to focus on a more clear and maintainable solution as part of #2039.

So it looks like the latest way our code is trying to use contact images is by first checking for an imageAvailable flag on a trustedContactsInfo item, then trying to access an image property from the same item if it’s true.

I still can’t find how either of these are being initialized in the first place, though, which is what we would need to fix in order to access images for display in the UI here. (@AliMeer @Parsh)

@cakesoft-nikhita Can you explain how a contact image is retrieved and used?

Spoke to Nikita, she is not able to figure where the image item went after the UI object and backend object related changes were made

Duplicate of  #3171

-Verified this issue on dev app v1.7.5(303)


Feat/tooltip and dep updates

I can't help but think this PR suggests we should just use chakra-ui and theme it for Blockstack, than spend so much time maintaining our own.

I can't help but think this PR suggests we should just use chakra-ui and theme it for Blockstack, than spend so much time maintaining our own.

@kyranjamie I def have considered that! We'd have to make some other choices, use emotion in place of styled-components, and would have overall less control of the components. But it's a super valid idea. I think there would be some places where it would not be ideal. If we decided to go with emotion, we could as-we-please just pull in things like @chakra-ui/tooltip and wrap it however we want and re-export it.

@hstove @kyranjamie mind following up with @aulneau's question above so we can move this issue along?

Compressed size actions are failing because of this error when running yarn: (babel plugin) Error: Cannot find module '@babel/helper-validator-identifier'
Also, there are some TS errors from react-router-dom. I recall that this is because their types are not up-to-date - we have some types in app/src/common/dev/types/react-router that we can shim for useNavigate. Happy to help there.


Fedora32 support

What problem does this feature solve?
I'm using fedora32 yet I can't install vue cli-service because it doesn't support fedora32. I would also like the ability for the users to use the beta version, which can sometimes be a fix when trying to troubleshoot an app.
Error that I get:
npm http request GET https://registry.npmjs.org/@vue%2Fcli-service
npm ERR! Linux 5.6.12-300.fc32.x86_64
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "i" "@vue/cli-service"
npm ERR! node v7.5.0
npm ERR! npm  v4.1.2
npm ERR! code EAI_AGAIN
npm ERR! errno EAI_AGAIN
npm ERR! syscall getaddrinfo
npm ERR! getaddrinfo EAI_AGAIN registry.npmjs.org:443
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     https://github.com/npm/npm/issues
npm ERR! Please include the following file with any support request:
npm ERR!     /app/npm-debug.log
What does the proposed API look like?
Just have a repo for Fedora32

The problem is not on the Vue CLI side, neither the OS version:

The node / npm version is too old. Vue CLI only supports Node.js v8.9+ (and v10.12+ is recommended because v8.x has reached end-of-life).
EAI_AGAIN is a network error that most likely caused by the DNS server. Please check your network setup.


Split spec files to examples programmatically

Instead of shelling out to rspec, we now split spec files into individual examples programmatically, using the RSpec Core API. This is faster and more robust, since we avoid common shell shenanigans.
Closes #6

This causes some failures on our internal builds. Will investigate and do a follow up. Closing it until then.


Removing important notice for Enterprise ring

The feature is now available in the Enterprise ring.  We no longer need to call out the build version that the feature is available in.

@nenonix @JohanFreelancer9 Copy editing is needed for this PR. Thanks.


Separate input and output directory settings

Follow-up of #340,

closes #303

Old behavior
When output was unset, "" or null it implicitly mirrored the value of input.
resource "iterative_task" "example" {
  ···
  workdir {
    input = "/path/to/input"
  }
}

New behavior
When output is unset, "" or null it will be disabled. Doesn't implicitly take the value of input anymore.
resource "iterative_task" "example" {
  ···
  workdir {
    input = "/path/to/input"
    output = "/path/to/output"
  }
}

Im not sure about this PR. What's the goal? There are scenarios where syncing back to current workdir is fine (CI in example)

What's the goal?

Fix #340: setting workdir.output to null will not synchronize back any artifacts.

There are scenarios where syncing back to current workdir is fine (CI in example)

In those scenarios, you can set workdir.input and workdir.output to the same value.

If I recall correctly, 🔔 @casperdcl also had a preference for the old output ||= input behavior. 🤔 Still, I believe that making input and output fully independent will be better in the long run.
🔔 @iterative/cml, any opinions/alternatives?

I see, but it's a funny mechanism to be guessed. We should at least document it through-fully.
Also, its not to me as interesting as the one I proposed in the original issue.
Reminder:

use a prop skip-output-sync

I consider this superior because changing it would allow to change your mind if we make this property non destructive.
And also is more explicit

A day without a 👍 👎 is not a proper day

Writing the explanation for the 👍🏼 👎🏼 ...

I believe that the behavior introduced with this pull request is cleaner and more explicit:[^1]

workdir {input = null, output = null} — don't push nor pull any data
workdir {input = "a", output = null} — push a on apply and don't pull on destroy
workdir {input = null, output = "b"} — don't push on apply and pull to b on destroy
workdir {input = "a", output = "b"} — push a on apply and pull to b on destroy

What you propose is a bit more complex to understand, at least for me: 🤔

workdir {input = null, output = null} — don't push nor pull any data
workdir {input = "a", output = null} — push a on apply and implicitly pull to a on destroy
workdir {input = "a", output = null, skip_output_sync = true} — push a on apply and don't pull on destroy

[^1]: explicit is better than implicit

I have never contemplated the idea of not pushing input data. I do not even envision too many scenarios like that.

workdir {input = "a", output = null} — push a on apply and implicitly pull to a on destroy

This is to my mind the most common and expected case. Something that already happens in the CI. If I generate artefacts during the task I want them to be in the same place as it would have been run locally.

I have never contemplated the idea of not pushing input data. I do not even envision too many scenarios like that.

There might be some users that don't want synchronizing a local working directory but want to retrieve the results after the execution. E.g. clone the repository as part of the script to reduce wait times.

This is to my mind the most common and expected case. Something that already happens in the CI.

You seem particularly focused on CI/CD scenarios. I wonder why. 😉

If I generate artefacts during the task I want them to be in the same place as it would have been if run locally.

Sure? Such a behavior would:

Overwrite files in the current directory, corrupting the Terraform state file and permanently undoing any local change made between apply and destroy
Produce several arcane errors (#306) when running destroy on several tasks that contain the same artifacts

I believe that the behavior introduced with this pull request is cleaner and more explicit:1

To my mind is not the case  because as I stated I think that the most expected way is

push a on apply and implicitly pull to a on destroy

clone the repository as part of the script to reduce wait times

I do not envision cloning the repo and work locally because that kills the experimentation. Should they change and immediately commit?
Also working in the CI they have already cloned

, or DVC–driven tasks.

DVC driven task use to need at least a dvc pipeline that needs to be pushed?
I might be wrong but we should probably discuss this urgently instead of taking  personal assumptions

To my mind is not the case because as I stated I think that the most expected way is: “push a on apply and implicitly pull to a on destroy”

In CI/CD systems this may hold true, but overwriting files as warned on https://github.com/iterative/terraform-provider-iterative/pull/395#issuecomment-1041330561 does't look like the most user–friendly experience for local users.

I do not envision cloning the repo and work locally because that kills the experimentation. Should they change and immediately commit?

🤔 Should we even assume that users have some version control system in place?

Also working in the CI they have already cloned

CI/CD scenarios are pretty clear and work as expected. 👍🏼

DVC driven task use to need at least a dvc pipeline that needs to be pushed?

But probably with DVC itself instead of rclone 🤷🏼♂ Just thinking ahead of time.

I might be wrong but we should probably discuss this urgently instead of taking personal assumptions

Shall we return to this page and refine the existing proposals or suggest new ones? 🤔

🤔 Should we even assume that users have some version control system in place?

No. But Im not expecting them to clone

overwriting files as warned on https://github.com/iterative/terraform-provider-iterative/pull/395#issuecomment-1041330561 does't look like the most user–friendly experience for local users.

Overwriting is the most common behaviour in the majority of the commands involving files. The issue here is wanting to do multiple runs in the same folder, but this is an scenario that is managed by a regular user on a daily basis. I would say

Shall we return to this page and refine the existing proposals or suggest new ones? 🤔

We already had a behaviour in place. The question is that introducing skip is altering completely the at-least-known-not-yet-validated behaviour.

You seem particularly focused on CI/CD scenarios. I wonder why. 😉

It's not because of the CI. Its because as stated I think is the most common way. Let's imagine that task is not running in the cloud. It's just a magical power that enhances our laptop making it able of training with GPU. As I stated the most common way to understand the output is that the artefacts are going to be in the place the script is generating them.
Also we should always reduce the complexity in the story. We can not say for local do a, for CI do b. Thats more confusing than say for local or CI do a

I'm not expecting them to clone

Sounds like a valid use case? 🤔

Overwriting is the most common behaviour in the majority of the commands involving files.

Overwriting is a common behavior in operations that explicitly take a list of files. Doesn't seem the expected behavior for such a complex process, especially when the working directory contains both the user's project and the Terraform code & state files.

The issue here is wanting to do multiple runs in the same folder, but this is a scenario that is managed by a regular user on a daily basis.

What do you mean by “managed by a regular user on a daily basis”? Is this process slow enough to not require any automation? 🤔

We already had a behaviour in place. The question is that introducing skip is altering completely the at-least-known-not-yet-validated behaviour.

Do you mean the original behavior, prior to #340?

It's not because of the CI. Its because as stated I think is the most common way. Let's imagine that task is not running in the cloud. It's just a magical power that enhances our laptop making it able of training with GPU. As I stated the most common way to understand the output is that the artefacts are going to be in the place the script is generating them.

Agreed! That's the behavior we had in place before #340, but that behavior caused #306 and overwrote local files with outdated copies.

Also we should always reduce the complexity in the story.

Agreed!

We can not say for local do a, for CI do b. Thats more confusing than say for local or CI do a

Sometimes, both a and b make sense for different use cases, and overloading the API (#324, #339, #389, #390) to be “consistent” for all of these use cases might be worse that letting users be aware of the differences. 🤔


Memory leak

Hi,
It seems like we have discovered a memory leak when using the Camunda Worker package.
According to dotMemory we are building up types of:

CancellationTokenSource
HttpClient
ExternalTaskClient
It slowly grows over time, with the rate increasing under load.

It seems to be caused by the way ExternalTaskClient is resolved inside ExternalTaskContext.
According to
https://docs.microsoft.com/en-us/dotnet/core/extensions/dependency-injection-guidelines#disposable-transient-services-captured-by-container
the container will hold onto these references forever.
Maybe the calls to GetRequiredService should be inside its own scope. I am not sure if transient services will be released on scope exit.
Have you noticed anything similar?
I will continue the investigation.

Simply removing the inheritance from IDisposable in IExternalTaskClient seems to remove the leaks of the mentioned object types.
As mentioned in the link above:

When you register Transient services that implement IDisposable, by default the DI container will hold onto these references, and not Dispose() of them until the application stops.

According to https://www.stevejgordon.co.uk/httpclient-creation-and-disposal-internals-should-i-dispose-of-httpclient it doesn't seem to be a big violation of some rule to skip disposing HttpClient objects..

Answer when using HttpClientFactory:
There is no need to dispose of the HttpClient instances from HttpClientFactory. Disposal will not actually do anything in this case because the factory manages the handler and connection lifetimes and not the HttpClient instances. Calling dispose on HttpClient has no effect for instances provided by the factory and is simply redundant code.

Hello,
Thank you for your feedback and the investigation!
I tried to reproduce described problem and I had seen that obtaining of IExternalTaskClient from root service provider really leads to memory leaks. The problem has more to do with ExternalTaskSelector (used in root scope) also uses IExternalTaskClient.

@sorjor-net the problem is resolved in 0.10.2


[Feature Request]  Make it a seperate option to disable/re-enable the "who to follow" options when disabling the "what's happening" sidebar

Hi,
I'm an artist, and while I do love most of the features of the program, the one part of the sidebar I still use is the "who to follow" part of the sidebar.  I want to be able to get rid of the "what's happening" sidebar, but I still want it to display the three related accounts on the side so I can find new artists I don't follow yet.  Would it be possible to add a sub-option to re-enable this part of the sidebar while removing the rest?

Or vice-versa, since I'm more interested in "What's happening" than "Who to follow."


svg file could not usb

hello,counld you tell me  what svg edit software you use to design svg file?  my svg file always show some mistake

Hi there,
I am typically either writing the SVG files by hand, or using an online conversion tool from non-SVG formats, such as https://picsvg.com/
The error shown can be fixed by adding support for text-elements in the code base. The code base is open source and in the public domain, so everyone in the World can contribute.


build(renovate): removing ng-mocks

v14.3.1 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


I am getting error when it is run

I want to use casper + phantom, not headless chrome.
Then, I have following source code.
require('babel-polyfill')
const Nick = require('nickjs')
const Promise = require('bluebird')

const nick = new Nick()

nick.newTab().then(async function(tab) {
  await tab.open("news.ycombinator.com")
  await tab.untilVisible("#hnmain") // Make sure we have loaded the page
  await tab.inject("/home/vagrant/test/nickjs_casper/src/js/jquery-3.3.1.slim.min.js") // We're going to use jQuery to scrape
  const hackerNewsLinks = await tab.evaluate((arg, callback) => {
    // Here we're in the page context. It's like being in your browser's inspector tool
    const data = []
    $(".athing").each((index, element) => {      data.push({
        title: $(element).find(".storylink").text(),
        url: $(element).find(".storylink").attr("href")
      })
    })
    callback(null, data)
  })
  console.log(JSON.stringify(hackerNewsLinks, null, 2))
})
.then(() => nick.exit())
.catch((err) => {
    console.log('Oops, an error occurred: ' + err)
    nick.exit(1)
})

But, I am getting the following error.
Oops, an error occurred: Error: in evaluated code (initial call): EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://cdnjs.cloudflare.com/".
Do you know why I am getting this error?

Did you manage to solve your issue?

Thanks for comment.
I did not solve yet.


set the right plugin path in settings.json on install

Signed-off-by: Christian Goll<EMAIL_ADDRESS>

Hm, I actually think that it could be worthwhile to make the plugin_path configurable, as not every distribution might want to install plugins to %_libdir (I think %_libexecdir might be a better fit depending on the distro policy).

@dcermak the plugins path is already configurable...

Hm, I actually think that it could be worthwhile to make the plugin_path configurable, as not every distribution might want to install plugins to %_libdir (I think %_libexecdir might be a better fit depending on the distro policy).

I just took the path of path which was already there, so this would require changes in other places. This pr, just makes the phoebe useable without the need of an extra edit of the configuration files.

@dcermak the plugins path is already configurable...

Not from meson though.

Hm, I actually think that it could be worthwhile to make the plugin_path configurable, as not every distribution might want to install plugins to %_libdir (I think %_libexecdir might be a better fit depending on the distro policy).

I just took the path which was already there, so this would require changes in other places. This pr, just makes the phoebe useable without the need of an extra edit of the configuration files.

Makes sense, then this PR looks good to me :+1:

Thanks @mslacken


pass arbitrary colors array to ring.startFlashing()

adds a tile.cue() method similar to tile.target()
for now if the target tile also has a cue, it will use the fill of the cue, white and grey for the flashing. else it will use the array of all common cue colors.

cool! LGTM


mvp-cockpit: 400 Bad Request when deploying new VDC on be-conv-2

blueprint:
g8client__cl:
  url: gig.demo.greenitglobe.com
  login: yves
  password: IAM4greenIT
  account: centrilogic

vdc__vdc4yves03:
  g8client: cl
  account: centrilogic
  location: 'be-conv-2'

actions:
  - action: install

after succesfully executing ays blueprint executing ays run fails:
root@vm-61:/optvar/cockpit_repos/yves03# ays run
Compute dependency graph...
RUN:8157ffb4da7d5ba874928ee3d4716638
-------
## step:1

step:1 (new)
- vdcfarm                   auto_2                    ! install         (new)
- g8client                  cl                        ! install         (new)

## step:2

step:2 (new)
- vdc                       vdc4yves03                ! install         (new)

Do you want to execute this run ? (y/n):y
[Tue06 13:22] - ...umpScale/baselib/jobcontroller/Run.py:72   - INFO     - execute job: vdcfarm!auto_2 (install)
[Tue06 13:22] - ...umpScale/baselib/jobcontroller/Run.py:72   - INFO     - execute job: g8client!cl (install)
[Tue06 13:22] - ...umpScale/baselib/jobcontroller/Run.py:137  - INFO     - job job: vdcfarm!auto_2 (install) done sucessfuly
[Tue06 13:22] - ...umpScale/baselib/jobcontroller/Run.py:137  - INFO     - job job: g8client!cl (install) done sucessfuly
[Tue06 13:22] - ...umpScale/baselib/jobcontroller/Run.py:72   - INFO     - execute job: vdc!vdc4yves03 (install)
Error of job: vdc!vdc4yves03 (install):
*TRACEBACK*********************************************************************************
Traceback (most recent call last):
  File "/opt/jumpscale8//lib/JumpScale/core/processmanager/ProcessManagerFactory.py", line 195, in start
    res = self.method(**self.args)
  File "/tmp/actions/vdc/install.py", line 10, in action
    acc = cl.account_get(service.model.data.account)
  File "/opt/jumpscale8//lib/JumpScale/clients/openvcloud/Client.py", line 147, in account_get
    maxNumPublicIP=maxNumPublicIP)
  File "/opt/jumpscale8/lib/JumpScale/clients/portal/PortalClient.py", line 43, in __call__
    raise ApiError(response)
JumpScale.clients.portal.PortalClient.ApiError: 400 Bad Request
Param with name:location is missing.

******************************************************************************************

**** TRACEBACK ***
Traceback (most recent call last):
  File "/opt/jumpscale8/bin/ays", line 538, in <module>
    cli()
  File "/opt/jumpscale8/bin/ays", line 46, in run
    run.execute()
  File "/opt/jumpscale8/lib/JumpScale/baselib/jobcontroller/Run.py", line 261, in execute
    raise j.exceptions.RuntimeError("Error during execution of step %d\n See stacktrace above to identify the issue" % step.dbobj.number)
JSExceptions.RuntimeError: ERROR: Error during execution of step 2
 See stacktrace above to identify the issue ((type:runtime.error)

According to @grimpy that's because this is an old env.


Fix logrotateadditionalfiles deletion.

This PR aims to fix a scenario whereby logrotateAdditionalFiles marked with deleteInExecutorCleanup would never actually be deleted. The scenario was:

Task terminates successfully
Executor runs the “immediate” cleanup logic
logrotateAdditionalFiles deletion is skipped because it hasn't been 15 minutes since task termination
Cleanup logic flows all the way through to https://github.com/HubSpot/Singularity/blob/4dea95764bdeee9f41046b4ad1c6a94a1e5dab8c/SingularityExecutor/src/main/java/com/hubspot/singularity/executor/task/SingularityExecutorTaskCleanup.java#L79
Task definition file is deleted
Scheduled executor cleanup will never be aware of this sandbox again

I’ve plumbed through some logic for log cleanup which is similar to the logic for the sandbox app/ directory cleanup. Which is to say, if it hasn’t been 15 minutes since task termination, we return a WAITING state from the “immediate” cleanup process. This way, we allow scheduled cleanup to take another look at it later, and properly delete files which we had been logrotating for the lifetime of the task.

Note that there are, broadly, three things to be cleaned up:

app dir
log files uploaded by Singularity (service.log and s3UploaderAdditionalFiles)
log files rotated by Singularity

With this PR, we're set up so that 2 and 3 are either performed or skipped together. Is this what we want? Should 1 and 2 happen together, with the 15 minute delay applying only to 3?

I think I agree that the 15 minute delay should apply to both 2 and 3. In particular because the S3Uploader needs a chance to get a at the logs for 2, which the 15 minute window is nice for.
Overall PR seems fine. I think it's gonna be a matter of testing the common cases in staging. Good find on where we clean the task definition file. Couldn't remember earlier where we actually were informed about a sandbox still hanging around

Tested successfully. The scenario described above now proceeds as follows:

Task terminates successfully
Executor runs the “immediate” cleanup logic
app/ directory is cleaned
All configured logfiles that are configured to be rotated, are rotated (and therefore, tail_of_finished_service.log is available approximately immediately, same as current master behavior)
logrotateAdditionalFiles deletion is skipped because it hasn't been 15 minutes since task termination
The immediate cleanup process returns a WAITING state and the task definition file isn't deleted
... 15 minutes later...
logrotateAdditionalFiles deletion proceeds
Task definition file is deleted
Scheduled cleanup process returns SUCCESS

🚢


OpenAPI trait can't find ConfigMap

Using Camel-K operator 1.8.0
I want to create an integration using an openapi spec in a configmap. The configmap looks like this:
apiVersion: v1
metadata:
  name: customer-credit-rating-openapi
  namespace: mercury
data:
  CustomerCreditRating.json: |-
...

Then I create an integration like the following:
spec:
  dependencies:
  - mvn:com.redhat.mercury:customer-credit-rating-common:1.0.1-SNAPSHOT
  - camel:protobuf
  flows:
   ...
  traits:
    environment:
      configuration:
        vars:
        - MERCURY_BINDING_SERVICE_HOST=customer-credit-rating
        - MERCURY_BINDING_SERVICE_PORT=9000
    openapi:
      configuration:
        configmaps:
        - customer-credit-rating-openapi

The operator fails to succeed with the following error:
{"level":"error","ts":1644271838.5132942,"logger":"controller.integration-controller","msg":"Reconciler error","reconciler group":"camel.apache.org","reconciler kind":"Integration","name":"customer-credit-rating-camelk-rest","namespace":"mercury","error":"error during trait customization: cannot generate configmap for openapi resource CustomerCreditRating.json: ConfigMap \"\" not found","errorVerbose":"ConfigMap \"\" not found\ncannot generate configmap for openapi resource CustomerCreditRating.json\ngithub.com/apache/camel-k/pkg/trait.(*openAPITrait).generateFromDataSpecs\n\tgithub.com/apache/camel-k/pkg/trait/openapi.go:167\ngithub.com/apache/camel-k/pkg/trait.(*openAPITrait).generateFromConfigmaps\n\tgithub.com/apache/camel-k/pkg/trait/openapi.go:157\ngithub.com/apache/camel-k/pkg/trait.(*openAPITrait).Apply\n\tgithub.com/apache/camel-k/pkg/trait/openapi.go:110\ngithub.com/apache/camel-k/pkg/trait.(*Catalog).apply\n\tgithub.com/apache/camel-k/pkg/trait/trait_catalog.go:113\ngithub.com/apache/camel-k/pkg/trait.Apply\n\tgithub.com/apache/camel-k/pkg/trait/trait.go:47\ngithub.com/apache/camel-k/pkg/controller/integration.(*platformSetupAction).Handle\n\tgithub.com/apache/camel-k/pkg/controller/integration/platform_setup.go:54\ngithub.com/apache/camel-k/pkg/controller/integration.(*reconcileIntegration).Reconcile\n\tgithub.com/apache/camel-k/pkg/controller/integration/integration_controller.go:309\ngithub.com/apache/camel-k/pkg/util/monitoring.(*instrumentedReconciler).Reconcile\n\tgithub.com/apache/camel-k/pkg/util/monitoring/controller.go:70\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:298\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:253\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214\nruntime.goexit\n\truntime/asm_amd64.s:1371\nerror during trait customization\ngithub.com/apache/camel-k/pkg/trait.Apply\n\tgithub.com/apache/camel-k/pkg/trait/trait.go:48\ngithub.com/apache/camel-k/pkg/controller/integration.(*platformSetupAction).Handle\n\tgithub.com/apache/camel-k/pkg/controller/integration/platform_setup.go:54\ngithub.com/apache/camel-k/pkg/controller/integration.(*reconcileIntegration).Reconcile\n\tgithub.com/apache/camel-k/pkg/controller/integration/integration_controller.go:309\ngithub.com/apache/camel-k/pkg/util/monitoring.(*instrumentedReconciler).Reconcile\n\tgithub.com/apache/camel-k/pkg/util/monitoring/controller.go:70\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:298\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:253\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214\nruntime.goexit\n\truntime/asm_amd64.s:1371","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214"}

I have used this approach successfully with kamel 1.8.0 but it no longer works.

cc @squakez

The problem seems to be related to a wrongly configured IntegrationPlatform. In my case it was missing the settings.xml
But the error message was pointing me to a completely different place.


diesel 2.0 support

Closes https://github.com/PPakalns/diesel_json/issues/2

Hello, thank you for providing changes to support new diesel version.
Will test these changes and release crate under new breaking changes version.

New version with necessary changes released:
diesel_json = "0.2.0"
Thank you!