text:
[SPARK-40811][SQL][TESTS] Use checkError() to intercept ParseException: phase 2

What changes were proposed in this pull request?
In the PR, I propose to port the following tests suites onto checkError to check valuable error parts instead of error messages:

ParserUtilsSuite
TableSchemaParserSuite
InsertSuite
HiveDDLSuite
SQLQuerySuite
MiscFunctionsSuite

Why are the changes needed?
Migration on checkError() will make the tests independent from the text of error messages.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
By running the modified test suites:
$ build/sbt "test:testOnly *.ParserUtilsSuite"
$ build/sbt "test:testOnly *.TableSchemaParserSuite"
$ build/sbt "test:testOnly *.InsertSuite"
$ build/sbt -Phive-2.3 -Phive-thriftserver "test:testOnly *HiveDDLSuite"
$ build/sbt "test:testOnly *SQLQuerySuite"
$ build/sbt "test:testOnly org.apache.spark.sql.MiscFunctionsSuite"

cc @panbingkun

@LuciferYang @panbingkun @itholic Could you review this PR, please.

Merging to master. Thank you, @panbingkun and @cloud-fan for review.

Late LGTM

authors: LuciferYang MaxGekk


text:
[SPARK-41855][CONNECT][PYTHON][FOLLOWUP] Make createDataFrame accept Decimal('NaN')

What changes were proposed in this pull request?
Make createDataFrame accept Decimal('NaN')
Why are the changes needed?
bugfix, refer to https://github.com/apache/spark/pull/34285
Does this PR introduce any user-facing change?
yes
How was this patch tested?
enabled test

cc @HyukjinKwon @Yikun

Merged to master and branch-3.4.

source: gharchive/pull-request

authors: HyukjinKwon zhengruifeng

repo: apache/spark

license_type: permissive

license_source: github-api


text:
[SPARK-43121][SQL] Use BytesWritable.copyBytes instead of manual copy in `HiveInspectors

What changes were proposed in this pull request?
https://github.com/apache/spark/blob/891a142b9141489f3872cc4c8b9ffd50a889f524/sql/hive/src/main/scala/org/apache/spark/sql/hive/HiveInspectors.scala#L625-L632
The above code comments are no longer applicable to the current Spark version , so this pr change to call BytesWritable.copyBytes directly.
https://github.com/apache/hadoop/blob/706d88266abcee09ed78fbaa0ad5f74d818ab0e9/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/BytesWritable.java#L69-L79
https://github.com/apache/hadoop/blob/rel/release-2.7.4/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/BytesWritable.java#L69-L79
Why are the changes needed?
Using existing BytesWritable api
Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass GitHub Actions

Merged to master, thanks!

Thank you for merging, @sunchao !

Thanks @sunchao @dongjoon-hyun

authors: LuciferYang dongjoon-hyun sunchao


text:
[MINOR][INFRA] Update the labeler for CORE and CONNECT

What changes were proposed in this pull request?
Update the labeler for CORE and CONNECT
Why are the changes needed?
1, existing CORE label actually match almost all python files under pyspark;
2, add ML on Connect to CONNECT label;
Does this PR introduce any user-facing change?
no, dev-only
How was this patch tested?
manually check

Merged to master.


text:
[SPARK-46999][SQL] ExpressionWithUnresolvedIdentifier should include other expressions in the expression tree

What changes were proposed in this pull request?

The plan/expression tree will be expanded during analysis, due to our implementation of the IDENTIFIER clause: we keep a lambda function in the plan/expression node to lazily return a new plan/expression.
This is usually fine, but doesn't work well with query parameter binding, which needs to see the entire plan/expression tree and bind all parameters at once. The feature EXECUTE IMMEDIATE also needs to see the entire plan tree to determine if it's a PosParameterizedQuery or NameParameterizedQuery.
This PR fixes the problem for ExpressionWithUnresolvedIdentifier, to make the lambda function only return the expression node that needs the identifier, and other expressions should be kept in ExpressionWithUnresolvedIdentifier and passed to the lambda function later.
PlanWithUnresolvedIdentifier will be fixed in a similar way in another PR.
Why are the changes needed?

To make IDENTIFIER clause work with query parameter binding
Does this PR introduce any user-facing change?

Yes, certain queries can run now while they failed before. See the test
How was this patch tested?

new test
Was this patch authored or co-authored using generative AI tooling?

No

cc @srielau @MaxGekk

thanks for the review, merging to master!


text:
[SPARK-7308][WIP] prevent concurrent attempts for one stage

Reproduction of multiple concurrent stage attempts, and a fix.  This actually doesn't completely solve the problem, but it is a vast improvement.  I wanted to put this up so others could take a look at the test case, since the DAGScheduler is tricky (the purpose of the PR at this point is mostly just the failure reproduction).
I'd recommend reviewers check out a branch with just has the failure reproduction, without the fix here: https://github.com/squito/spark/tree/SPARK-7308_failure_reproduction.  Run this test -- even just watch the logs with tail -f core/targer/unit-tests.log | grep DAGScheduler and you will see some really weird behavior: Stage 2 has multiple concurrent attempts, which appear to stomp all over each other; Stage 3 get submitted before Stage 2 ever finishes, and then it will rapidly fire off a bunch of attempts which all quickly die (I've seen > 50 attempts); and lots of executors continue to get lost, though the test case only simulates one executor getting lost.
Even with the fix here atm, we still see concurrent attempts for stage 3, and the first several die from corrupted streams.  However, these failures are recovered from consistently -- the job completes successfully.  But, that could be just b/c the test case isn't complicated enough, so that definitely needs to be fixed as well.  I have a vague idea of how its happening and think I can fix it.

Merged build triggered.

Merged build started.

Test build #32073 has started for   PR 5964 at commit 7fbcefb.

Test build #32073 has finished for   PR 5964 at commit 7fbcefb.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Merged build triggered.

Merged build started.

Test build #32076 has started for   PR 5964 at commit 2eebbf2.

Test build #32076 has finished for   PR 5964 at commit 2eebbf2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

Build triggered.

Build started.

Test build #32558 has started for   PR 5964 at commit 05c72fd.

Test build #32558 has finished for   PR 5964 at commit 05c72fd.

This patch fails Scala style tests.
This patch does not merge cleanly.
This patch adds the following public classes (experimental):
class SparkIllegalStateException(message: String, cause: Throwable)
class IndexShuffleBlockManager(conf: SparkConf) extends ShuffleBlockResolver with Logging

Build finished. Test FAILed.

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

Merged build triggered.

Merged build started.

Test build #32564 has started for   PR 5964 at commit 31c21fa.

Test build #32564 has finished for   PR 5964 at commit 31c21fa.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #32628 has started for   PR 5964 at commit 93592b1.

Test build #32628 has finished for   PR 5964 at commit 93592b1.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class SparkIllegalStateException(message: String, cause: Throwable)

Merged build finished. Test FAILed.

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

Merged build triggered.

Merged build started.

Test build #32630 has started for   PR 5964 at commit ea2d972.

Test build #32630 has finished for   PR 5964 at commit ea2d972.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class SparkIllegalStateException(message: String, cause: Throwable)

Merged build finished. Test PASSed.

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

Merged build triggered.

Merged build started.

Test build #33278 has started for   PR 5964 at commit 6654c53.

Test build #33278 has finished for   PR 5964 at commit 6654c53.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class SparkIllegalStateException(message: String, cause: Throwable)
        s" but class priors vector pi had $
        s" but class conditionals array theta had $
class KernelDensity extends Serializable

Merged build finished. Test FAILed.

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

Merged build triggered.

Merged build started.

Test build #33291 has started for   PR 5964 at commit dd2839d.

Test build #33291 has finished for   PR 5964 at commit dd2839d.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class SparkIllegalStateException(message: String, cause: Throwable)

Merged build finished. Test PASSed.

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

Would love to get some feedback from the scheduler maintainers: @mateiz @markhamstra @kayousterhout @pwendell

I haven't yet looked at this closely, but is it possible to split this change into different pull requests, one for each issue?

@kayousterhout I debated doing that, but I kept them together b/c my test case produces all four.  So I wouldn't have passing tests unless I addressed them all.  (Though I could actually relax the criteria in the test so 3 & 4 were unnecessary.)
To put it another way: I'm happy to restructure this for merging.  But, I feel that reviewers should consider all of the issues together to properly grasp what is going wrong in the existing implementation.  Again, I'd like to stress running the reproduction and seeing what is wrong (ideally adding a loop and running it many times) , that is far more important than the diff for reviewing this IMO.
Though maybe this also leads to another question for reviewers -- how do you feel about that test?  Its unlike our other unit tests, in that it doesn't try to very narrowly recreate one issue.  instead it simulates a workload, with some randomization.  The downside of that test is, its slow and you can't easily tease apart the different issues into separate tests.  But the upside is that you actually get better coverage -- eg., I wouldn't have discovered issue (2) without this.

all that said, I do see the value in separating them out as well, so I'll do that in addition.  But I'd still like reviewers to consider this holistically :)

Mostly I care about separating (1), since it seems like its handling is totally separate from the other issues; can you put the fix to that in its own pull request (or move the other changes into their own pull request)?  For that issue, it seems possible to write a narrow unit test to test the specific issue (I wrote two such tests here that you should be able to mostly re-use, if you like: https://github.com/kayousterhout/spark-1/commit/2b7d23299251a858f13e600d58bb616bf38d7c73; the first test passes but the second one fails with the current code).  I find that preferable to the end-to-end test that you wrote, since it makes it easier to debug the issue when the test fails, and the test also runs much more quickly.
I'm also a little confused about how this fixes (1), as I commented on in the code.

closing, since I've broken this into separate prs -- thanks for the comments everyone, would appreciate reviews of https://github.com/apache/spark/pull/6648 and https://github.com/apache/spark/pull/6750

authors: AmplabJenkins SparkQA kayousterhout squito


text:
SPARK-8916 [Documentation, MLlib] Add @since tags to mllib.regression

Added @since tags to mllib.regression

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@JoshRosen I reformatted the comments now. Also added a few more tags I had missed. Please take a look.

Formatting seems fine to me, but I'll let @mengxr or @jkbradley do the final sign-off on this (I'm not really a MLlib reviewer).
Jenkins, this is ok to test.

Thanks Josh!

cc @dbtsai

ok to test

Merged build triggered.

Merged build started.

Test build #37875 has started for   PR 7518 at commit 1a0365f.

Test build #37875 has finished for   PR 7518 at commit 1a0365f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

In general: we need not add tags to equals, hashCode, toString and private / protected methods. Please make those changes

Update: There is now an annotation which we're using instead of the since tag: [https://issues.apache.org/jira/browse/SPARK-9864]  Would you mind updating this to use the annotation?  Thanks!

@prayagchandran It will be great to merge this ASAP to include it in the 1.5 RC.  I'll watch for updates.  Thanks!

Merged build triggered.

Merged build started.

Test build #40906 has started for   PR 7518 at commit 6c6d584.

Merged build triggered.

Merged build started.

Merged build finished. Test FAILed.

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

Test build #40906 has finished for   PR 7518 at commit 6c6d584.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

@dbtsai Do you have time to make a final pass?

Thanks. Merged into master and 1.5 branch.

authors: AmplabJenkins JoshRosen MechCoder SparkQA dbtsai jkbradley mengxr prayagchandran


text:
[SparkSPARK-9340] - make SparkSQL work with nested types in parquet-p…

…rotobuf files

Can one of the admins verify this patch?

@dguy,  please do the PR against the Master branch.
Thank you.

Please close this PR in favor of #8063.
Thank you.

authors: AmplabJenkins dguy nssalian


text:
[STORM-2834] getOwnerResourceSummaries not working properly because scheduler is wrapped as BlacklistScheduler

https://issues.apache.org/jira/browse/STORM-2834
The condition of scheduler instanceof ResourceAwareScheduler or scheduler instanceof MultitenantScheduler will never be true because the scheduler is wrapped as BlacklistScheduler
Tested it manually.

@revans2  There is now - https://issues.apache.org/jira/browse/STORM-2840

authors: Ethanlm govind-menon

repo: apache/storm


text:
STORM-3119: Build Storm with Java 10

https://issues.apache.org/jira/browse/STORM-3119
There are some changes in this PR that are only tangentially related to building with JDK10, namely fixes to some flaky tests that would have made it a pain to add extra test runs to every PR.
Changes:

Add Java 10 to the Travis build matrix. Storm-cassandra and storm-hive are excluded, because Cassandra and Hive aren't Java 9+ compatible yet.
Add relevant Java EE APIs to components that use Jersey. The Java EE APIs aren't available without add-modules in Java 9+, so we should include them explicitly as dependencies. This is already done in most of the components, but missed a few spots.
The integration test Vagrant box has been updated so the user's name is vagrant rather than ubuntu, fix this in the scripts
Added environment variable to allow people to use Java 10 in integration tests run via Vagrant
Fixed the integration test so it runs on Java 10. The default worker.childopts include removed JVM parameters related to GC logging. There doesn't appear to be parameters that work on both Java 8 and 10, so we'll need to add to the documentation how people should override the worker.childopts, if they want to run on Java 10.
Some of the Time code didn't make sense, e.g. checking for null on the final THREAD_SLEEP_TIMES_NANOS map. It was left over from an earlier refactor of Time. Cleaned it up, and deleted the deprecated Time methods. Also made sure that when simulated time is advanced, idle threads are removed from the THREAD_SLEEP_TIMES_NANOS immediately. When the LocalCluster waits for the topology to be idle, it checks whether all timer threads are in the THREAD_SLEEP_TIMES_NANOS map. It looks to me like there was no guarantee that sleeping threads actually got a chance to run when time was advanced, because they remained in the THREAD_SLEEP_TIMES_NANOS map until they happened to be scheduled. With bad luck, a thread might end up being counted as idle when it just hadn't exited the Time.sleepUntilNanos loop yet.
The metrics-tests were doing assertions in a racy way. We can't guarantee that metrics fall in exact buckets, because the metrics are updated from the executor async loops, which aren't included in the threads covered by LocalCluster.waitForIdle. I've replaced the checks with validation that there are a certain number of metrics buckets, and that the metrics counters sum to the expected value.

Example of a failing metrics test:
classname: org.apache.storm.metrics-test / testname: test-custom-metric-with-multi-tasks
expected: (clojure.core/= [1 0 0 0 0 0 2] (clojure.core/subvec (org.apache.storm.metrics-test/lookup-bucket-by-comp-id-&-metric-name! "2" "my-custom-metric") 0 N__3207__auto__))
  actual: (not (clojure.core/= [1 0 0 0 0 0 2] [1 0 0 0 0 0 0]))
      at: test_runner.clj:105

In this case the missing 2 counts happen in a later bucket than the test is checking for, because the executor async loop happened to not have run when the metrics system added the last bucket.
Let me know if I need to split this PR up, or if a change is unclear. I ran the tests a few times on Travis, and they appear stable.

The metrics-tests were doing assertions in a racy way. We can't guarantee that metrics fall in exact buckets, because the metrics are updated from the executor async loops, which aren't included in the threads covered by LocalCluster.waitForIdle. I've replaced the checks with validation that there are a certain number of metrics buckets, and that the metrics counters sum to the expected value.

If it is not relevant to JDK 10, it would be better to split this PR up to have individual fix for flaky test. While someone wonders why we consider about Java 10 at all, the fix for flaky test is straightforward to be reviewed and merged sooner.

Fair enough, will split this up.

Pulled metrics test changes and Time changes into https://github.com/apache/storm/pull/2735 and https://github.com/apache/storm/pull/2734. Will rebase this once those get merged.

Just merged in your other PR, you might want to rebase to resolve the conflict.

@revans2 Rebased

I assume that you got the integration tests to pass in travis under JDK10?  I ran them manually and got a failure too.

@revans2 Yes, they run for me locally and on https://travis-ci.org/srdo/storm/builds/397471375. I'll try to figure out why the test is flaky, but it might take a while.

I would almost rather disable the integration test for java 10 until we can make it work cleanly.

I'll try running it a bunch of times, see if I can figure out why it's failing.

authors: HeartSaVioR revans2 srdo


text:
STORM-1016: Generate trident bolt ids with sorted group names

PR for STORM-1016

@victor-wong these changes look good, but would it be cleaner to just use a TreeMap instead of a HashMap?

@victor-wong any update on this?

@revans2 sorry for replying so late, I just made some changes and it worked OK. Is that what you mean?

@victor-wong yes that is exactly what I was thinking, makes the code a lot smaller.  I am +1 on this change, but it looks like there is a code conflict.  Could you upmerge your changes?
And don't worry about it taking a while.

@revans2 changes upmerged. Is that right?

The build is complaining that storm-core/test/jvm/storm/trident/TestTridentTopology.java does not have an apache license header.

Two very minor things, and I am +1

done :)

+1


text:
Fix incorrect encoding strings in FileUploadInterceptorTest

Fix incorrect encoding strings provided in FileUploadInterceptorTest

Tests were using "text/html" which is not a valid character encoding. No impact currently, but the tests could fail in the future if this is not corrected.  If the code is re-used elsewhere for a test of an action a
valid encoding will be needed.
Switch to a predefined constant Charset to get the string instead.

I wonder if it would be enough to integrate those kind of fixes into the master branch. This would minimize the number of changes for maintenance branches.

Hi.  This is a minor correction for future-proofing the FileUploadInterceptorTest.
The incorrect encoding was discovered when trying to build a unit test of an action with a mock file upload based on this test  (and UnsupportedEncodingException arose).
It will be easy to cherry-pick into 2.6.x as well.

Hi @sepe81.  I think I see your point concerning master vs. maintenance branches, but since it was found within 2.5.x first I figured it should be fixed there first.  A PR for the master branch alone could be done, but a fix in 2.5.x and cherry-pick into 2.6 should be pretty simple for this one.
I'm fine either way ... we can wait and see if anyone else prefers one over the other.

Coverage remained the same at 47.069% when pulling ce467b7fa51d8cd98d19665c965a4bcc88553778 on JCgH4164838Gh792C124B5:local_25x_TstFix1 into 73eb6ed189cd3e3625a11cdeb213d948f611a9bf on apache:struts-2-5-x.

Thanks for the quick reply @JCgH4164838Gh792C124B5 -- I am OK either way, too. Just wanted to express my thoughts on that AND hope to see version 2.6 one day. ;-)

@sepe81 is right, please focus on Struts 2.6 :) I rather do not expect to release one more 2.5.x version.

repo: apache/struts


text:
log4j 2.17.0

https://logging.apache.org/log4j/2.x/security.html

Coverage remained the same at 50.509% when pulling e29edc84e1bae6ddd090d03744b941a25befecd6 on sullis:log4j-2.17.0 into 9ca84ca02f9049d1e1ab68a338a2886052ec57e9 on apache:master.

authors: coveralls sullis


text:
[Dashboard]Native filter scoping tab should capture chart title change on dashboard

In below video you can see that table "Publishers With Most Titles" had a title changed to "Top 10 Games (by Global Sales)" on Dashboard. Filter scoping only picks up the original titles in the config modal, which caused some confusion.....
Expected behavior: chart title change on dashboard should also update the chart name, vise versa. Filter scoping tab should capture and show the latest title whether user changes it from Explore or Dashboard.
https://user-images.githubusercontent.com/67837651/120873157-d0266000-c555-11eb-873a-7c0a37c591bd.mov

This has been fixed / can no longer repro this issue

source: gharchive/issue

authors: junlincc yousoph

repo: apache/superset


text:
BigQuery Shared DataSets Schema is Not Showing in SQL Lab

A clear and concise description of what the bug is.
Expected results
I have datasets belongs to some other GCP Project, which has been shared to our in house GCP Project, our service account has access to it.
We Created  a connection to our GCP Project, which was successful and on SQL Lab we are able to run the queries to datasets belongs to other GCP PROJECT.
i.e select * from some_other_project.data_set.schema.
But in SQL LAB  i.e in Schema and Table Drop Down those datasets are not visible.
How we can create a new data connection which can show us the schemas and tables belong to the other GCP PROJECT as our service account has access to it ?
From the logs it try to query this :
"POST /bigquery/v2/projects/My_other_GCP Project/jobs getting  403 None as we don't have job permission to that project
My Connection :
bigquery://MY_OTHER_GCP_PROJECT
Provided our service account json in extra parameters.
Actual results
Able to connect to other shared GCP project using  service account json which has access to the datasets.

It's working with your trick but in this case Bigquery processing cost is apply on second projet.
It's also not possible to have sql query join data from multiple projets.

I would like to add that using shared datasets will allow easy try to use Superset, thanks to public datasets of BigQuery: https://cloud.google.com/bigquery/public-data

Tempted to close this one as stale and semi-resolved anyway... does anyone see value in keeping this open? CC @betodealmeida

Closing this as stale since it's been silent for so long, and we're trying to steer toward a more actionable Issues backlog. If people are still encountering this in current versions (currently 3.x) please re-open this issue, open a new Issue with updated context, or raise a PR to address the problem. Thanks!

authors: Guillaume-bytel ad-m codegeekjk rusackas


text:
[d&d][bubble chart] 'Bubble size' seems able to accept drop from 'Metric for color' and Run query will lead to chart fail

'Bubble size' seems able to accept drop from 'Metric for color' without any highlight, after drop a component, the Run button will show, but the 'Bubble size' did not change to option, then after clicking Run will show error for chart
Expected results
'Bubble size' able to accept drop from 'Metric for color' with highlight and change to new drop name, then show Run button.
Actual results
'Bubble size' able to accept drop from 'Metric for color ' without highlight and did not change to new drop name, but Run button show.
Screenshots
https://user-images.githubusercontent.com/81597121/127794284-dfe486d6-7017-40ce-9640-ecfeeeecf0ac.mov
How to reproduce the bug

Open bubble chart 'Location of current Developer'
Drag and Drop the 'Metric for color' option to 'Bubble size'
4.See error

Environment
(please complete the following information):

superset version: master
python version: python --version
node.js version: node -v
any feature flags active:

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

Fix: https://github.com/apache/superset/pull/16020

authors: jinghua-qa kgabryje


text:
docs: Add docs for GLOBAL_ASYNC_QUERIES (SIP-39)

SUMMARY
Adds documentation for GLOBAL_ASYNC_QUERIES feature, including all configuration settings. See https://github.com/apache/superset/pull/11499 for related code.
ADDITIONAL INFORMATION

[x] Has associated issue: https://github.com/apache/superset/issues/9190
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #12573 (f33f2bf) into master (deebd6f) will decrease coverage by 3.66%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #12573      +/-   ##
==========================================
- Coverage   66.75%   63.08%   -3.67%
==========================================
  Files        1015      486     -529
  Lines       49633    29950   -19683
  Branches     4839        0    -4839
==========================================
- Hits        33133    18895   -14238
+ Misses      16377    11055    -5322
+ Partials      123        0     -123

Flag
Coverage Δ

cypress
?

javascript
?

python
63.08% <ø> (-0.88%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/databases/commands/create.py
32.65% <0.00%> (-59.19%)
:arrow_down:

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.24%)
:arrow_down:

superset/views/database/mixins.py
59.64% <0.00%> (-22.81%)
:arrow_down:

superset/db_engine_specs/presto.py
70.56% <0.00%> (-11.48%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/databases/schemas.py
93.40% <0.00%> (-6.05%)
:arrow_down:

superset/databases/dao.py
94.11% <0.00%> (-5.89%)
:arrow_down:

superset/databases/api.py
86.55% <0.00%> (-5.47%)
:arrow_down:

... and 549 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #12573 (f33f2bf) into master (deebd6f) will decrease coverage by 3.66%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #12573      +/-   ##
==========================================
- Coverage   66.75%   63.08%   -3.67%
==========================================
  Files        1015      486     -529
  Lines       49633    29950   -19683
  Branches     4839        0    -4839
==========================================
- Hits        33133    18895   -14238
+ Misses      16377    11055    -5322
+ Partials      123        0     -123

Flag
Coverage Δ

cypress
?

javascript
?

python
63.08% <ø> (-0.88%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/databases/commands/create.py
32.65% <0.00%> (-59.19%)
:arrow_down:

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.24%)
:arrow_down:

superset/views/database/mixins.py
59.64% <0.00%> (-22.81%)
:arrow_down:

superset/db_engine_specs/presto.py
70.56% <0.00%> (-11.48%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/databases/schemas.py
93.40% <0.00%> (-6.05%)
:arrow_down:

superset/databases/dao.py
94.11% <0.00%> (-5.89%)
:arrow_down:

superset/databases/api.py
86.55% <0.00%> (-5.47%)
:arrow_down:

... and 549 more

Continue to review full report at Codecov.

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

we cut rc4 and kicked off the vote. Async query docs can go in the patch release, right?

we cut rc4 and kicked off the vote. Async query docs can go in the patch release, right?

authors: codecov-io junlincc robdiciuccio


text:
traffic router re-authentication on unauthorized

Traffic router pulls the steering and federation cfg directly for traffic-ops.
Every time it pulls the cfg, it tests if the cookie is still valid (by date only), and re-login if needed.
However, if the OPs fails and new OPs is put up instead, the router will not relogin as long as the cookie date is valid.
TR log will have the below messages indicating 401 http response.
This PR asks to fix it, by re-login in this case.
INFO  2018-01-25T13:46:28.467 [pool-9-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.monitor.TrafficMonitorWatcher - Loading properties from /opt/traffic_router/conf/traffic_monitor.properties
INFO  2018-01-25T13:46:44.633 [pool-1-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: federations.json; timeout is 15000
WARN  2018-01-25T13:46:44.689 [pool-1-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed Http Request to federations.json Status 401

@elsloo can you please take a look?
Thanks,
Nir

@ajschmidt can you review this?

I believe this bug might've been experienced when upgrading to 3.1.x due to an issue with TO cookie generation -- basically TO was expiring the cookie earlier than the cookie headers actually said. This led TR to believe it still had a valid cookie, except TO was treating it as expired. This led to TR getting stuck on 401 responses without attempting to re-authenticate. However, this TO issue should be fixed in 4.0.x per https://github.com/apache/trafficcontrol/pull/4119.
So now, TR will see that the cookie is expired then re-authenticate. However, this might not fix the issue of changing the TO secret, which I believe would essentially log everyone out and require everyone to log back in. In that case, this PR might be needed, but we should test that out.

@rawlinp I just tested and this works great (I changed the secret).
Here's the proof from the log.
INFO  2020-10-05T22:44:47.993 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: https://cdn1cdcms0001.coxlab.net/internal/api/1.3/steering.json; timeout is 15000
INFO  2020-10-05T22:44:48.039 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: https://cdn1cdcms0001.coxlab.net/api/1.2/user/login; timeout is 15000
INFO  2020-10-05T22:44:48.056 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: https://cdn1cdcms0001.coxlab.net/internal/api/1.3/steering.json; timeout is 15000
INFO  2020-10-05T22:44:48.275 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.loc.AbstractServiceUpdater - [SteeringWatcher] database unchanged.

Just to be clear. Without this fix, changing the secrets results in Status Code 401. Traffic Router needs restarted.

Nice, that is good to know. @nir-sopher would you like to rebase this PR and resolve the merge conflict?

@rawlinp Should we re-create this PR. the branch is not available anymore from Nir repository.

Sure, I will get around to it soon unless you want to.

Closing this pull request and re-opening a new one.

Just in case it ever matters to anyone, the new PR is #5177.

repo: apache/trafficcontrol


text:
TP: Provides the ability to view all users for a given role

What does this PR (Pull Request) do?

allows the result of GET /api/users to be filtered by role
Provides a view in TP to view users of a specific role

[x] This PR is not related to any Issue

Which Traffic Control components are affected by this PR?

Documentation
Traffic Ops
Traffic Portal

What is the best way to verify this PR?

Run the TO API tests and ensure they all pass
Launch TP and navigate to User Admin > Roles > Role and then select View Users and ensure that only users of the selected role are displayed.

The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4905/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4906/

I'm getting the following failures when running the v1 tests
user_test.go:305: users get: RoleName expected admin actual disallowed
user_test.go:318: users get: RoleName expected operations actual disallowed

Did you rebuild your traffic ops? I was seeing that error until I did a rebuild.

I thought so, but after rebuilding again that fixed the issue.


text:
Incorrect Error Check in function SSL_write()

Hi,
Function SSL_write() returns the value of 0 and less than 0 are both on error. However , the return value of function SSL_write() is not checked correctly, which forgot to check the return value 0. See the following code:
line : 1098, 1101
https://github.com/apache/trafficserver/blob/5ee6a5f554880b02535e6ee84268df922e87274d/tools/http_load/http_load.c#L1097-L1106
The same situation is  also occured on line 1216, 1219
https://github.com/apache/trafficserver/blob/5ee6a5f554880b02535e6ee84268df922e87274d/tools/http_load/http_load.c#L1215-L1224
===============================================================================
We find the return value of this call been checked in openssl project with the version of openssl 1.1.2.
Such as in openssl/apps folder
Ref : https://github.com/openssl/openssl/blob/0db957dbbcf6a432086ab913378c23636d8c374c/apps/s_time.c#L231-L232
line 231:     if (buf_len <= 0 || SSL_write(scon, buf, buf_len) <= 0)
line 232:         goto end;

Chi Li, Zuxing Gu, Jiecheng Wu

Relates to #4293

@lc3412 Can you please make a PR for this?

repo: apache/trafficserver


text:
Confine some warning flags to GNU compiler builds

This fixes some Clang warnings about warning flags not being recognized by only setting -Wno-format-truncation and -Wno-stringop-overflow for the GNU compiler.

[approve ci fedora]


text:
Add Remap ACL table test

This change adds a table test that tests every combination of ACLs, namely:

remap.config inline rule
named ACLs in remap.config.
ip_allow.yaml.

It tests the expected response for a GET request (explicity denied or allowed in the test) and a POST (implicitly denied or allowed by the GET rule)
The current test implementation is optimised for minimal code changes. Because of this a new server is started for each test. Because of this the new tests alone will add 1m20s to the total autest testing time.
This could be optimised if we feel that this style of test is worth considering.

This is now being worked on in #11433


text:
Some tidying up of the global namespace.

Add a TsStatus class that replaces stop_ssl_handshake, ts_is_draining, shutdown_event_system.

Other than removing Data and having those members as direct static members, seems reasonable. I would like @duke8253 to take a look.

On the subject of more verbosity, we may want this to be TSSystemState, as TsStatus could easily be confused with a normal return code (e.g. TSHttpStatus, TSRemapStatus).

Seems fine to me.

[approve ci debian]

authors: SolidWallOfCode bryancall ywkaras


text:
[build][tir] suppress -Woverloaded-virtual warning

Suppress a spurious -Woverloaded-virtual clang warning for the tvm::tir::DataTypeRewriter class.
I think we're safe to ignore clang version for this pragma, because it's been supported for a long time now.

CC: @Lunderberg

@vinx13 : I've updated the PR to mark the new methods as protected, because IIUC that's more in line with your original intentions.
I left the #pragmas in place, because using protected wasn't sufficient to make the warning go away.

I've reworked this based on our discussion:

The warnings are eliminated via using statements, rather than pragmas.
I changed the methods from public to protected, to better match (AFAICT) @vinx13 's intent.

@Lunderberg @vinx13 : Ready for review imho.

Can we apply a similar change in the DataTypeLegalizer? (Either as part of this PR or another.) It has the same issue of the VisitStmt_ methods being exposed, when external users should go through StmtExprMutator::operator() instead.

Thanks for the idea! It's not too much scope creep, so I'll add that to this PR.

repo: apache/tvm


text:
Add methods to get the size of VTCM on device as well as the allocated size of the HexagonVtcmPool

Expose methods so that callers can get both the size of VTCM on device as well as the allocated size of the pool for the session.
cc: @masahi

Can we expose the API to python too?

authors: janetsc masahi


text:
[topi] Add arm_cpu specific pooling schedules

This commit:

Adds specialized arm_cpu pooling schedules for both fixed width and salable vectors.
Enables topi testing of new arm_cpu schedules.

Will leave open for a bit longer to give chance for any final comments

Thanks @lhutton1. This has been open for almost two months now, so hopefully everyone who it might affect has had a chance to see it. I haven't got write permissions, so feel free to merge when you think its ready.

NOTE: this PR causes a regression in importing order:
Traceback (most recent call last):
  File "/root/Projects/tvm-dev/main.py", line 10, in <module>
    from tvm.testing import local_run
  File "/root/Projects/tvm-dev/python/tvm/testing/__init__.py", line 21, in <module>
    from . import auto_scheduler, autotvm
  File "/root/Projects/tvm-dev/python/tvm/testing/auto_scheduler.py", line 20, in <module>
    from tvm import auto_scheduler, te, topi
  File "/root/Projects/tvm-dev/python/tvm/topi/__init__.py", line 51, in <module>
    from . import nn
  File "/root/Projects/tvm-dev/python/tvm/topi/nn/__init__.py", line 35, in <module>
    from .conv3d_transpose import *
  File "/root/Projects/tvm-dev/python/tvm/topi/nn/conv3d_transpose.py", line 21, in <module>
    from tvm import relay
  File "/root/Projects/tvm-dev/python/tvm/relay/__init__.py", line 29, in <module>
    from . import prelude
  File "/root/Projects/tvm-dev/python/tvm/relay/prelude.py", line 21, in <module>
    from tvm.relay.transform import ToANormalFormExpr
  File "/root/Projects/tvm-dev/python/tvm/relay/transform/__init__.py", line 22, in <module>
    from . import fake_quantization_to_integer, mixed_precision
  File "/root/Projects/tvm-dev/python/tvm/relay/transform/fake_quantization_to_integer.py", line 25, in <module>
    from tvm.relay.qnn.op import canonicalizations
  File "/root/Projects/tvm-dev/python/tvm/relay/qnn/__init__.py", line 20, in <module>
    from . import op
  File "/root/Projects/tvm-dev/python/tvm/relay/qnn/op/__init__.py", line 21, in <module>
    from .qnn import *
  File "/root/Projects/tvm-dev/python/tvm/relay/qnn/op/qnn.py", line 26, in <module>
    from tvm.relay.op.nn.utils import get_pad_tuple2d
  File "/root/Projects/tvm-dev/python/tvm/relay/op/__init__.py", line 35, in <module>
    from . import strategy
  File "/root/Projects/tvm-dev/python/tvm/relay/op/strategy/__init__.py", line 24, in <module>
    from . import arm_cpu
  File "/root/Projects/tvm-dev/python/tvm/relay/op/strategy/arm_cpu.py", line 29, in <module>
    from ....topi.arm_cpu.mprofile import dsp
  File "/root/Projects/tvm-dev/python/tvm/topi/arm_cpu/__init__.py", line 33, in <module>
    from . import qnn_alter_op
  File "/root/Projects/tvm-dev/python/tvm/topi/arm_cpu/qnn_alter_op.py", line 25, in <module>
    from ..nn import qnn_conv2d_alter_layout, add_alter_layout, qnn_requantize_alter_layout
ImportError: cannot import name 'qnn_conv2d_alter_layout' from partially initialized module 'tvm.topi.nn' (most likely due to a circular import) (/root/Projects/tvm-dev/python/tvm/topi/nn/__init__.py)

Thanks @junrushao for the quick catch. I had a quick look into this but I wasn't able to reproduce the issue. Do you have a small script I could try out?

authors: FranklandJack junrushao lhutton1


text:
[TIR] Enhance Lower cross thread Pass

We currently only support lower cross thread with several constrains. For example, the lower_cross_thread only apples when the thread binding reduced axis is the innermost loop, and the block must have an init block. This can be a limiting for some cases.
For example, when tensorizing the reduction block (e.g., dp4a or mma), it becomes difficult to tensorize the init statement as well:
with T.block("block"):
    vi = T.axis.spatial(2, i_0 * 16 + i_1)
    vk = T.axis.reduce(32, k_0 * 64 + k_1)
    T.where(i_0 * 16 + i_1 < 2 and k_0 * 64 + k_1 < 32)
    T.reads(A[vi, vk])
    T.writes(B[vi])
    with T.init():
        B[vi] = T.float32(0)
    B[vi] = B[vi] + A[vi, vk]

Moreover, certain cases, like small gemm, prefer block reduction in shared memory to enhance parallelization to better utilize the hardware resources.
This pull request improves the lower_cross_thread pass, it can now handle the thread block reduce lowering with separate init and reduce blocks, and removes the constrain that the reduced axis is the innermost loop to support TensorCore with block reduction.
relevant test cases can be found at tests/python/tir-transform/test_tir_transform_lower_cross_thread_reduction.py.
Please CC @MasterJH5574 .

@LeiWang1999 please fix the lint and test case, @wrongtest-intellif do you mind help review the PR

I’m attempting to remove theLoopVar with ForNode, and I’ve encountered an unexpected behavior.
For new_for = For(ax_lane_id, Integer(0), warp_size, ForKind::kThreadBinding, n->body);
const ForNode* new_for_node = new_for.get();
LOG(INFO) << "new_for->min " << new_for_node->min;
// Output: 0

This snippet works fine and logs the expected output of 0 for new_for->min.
However, when I try to instantiate new_for_node directly, like this:
const ForNode* new_for_node = For(ax_lane_id, Integer(0), warp_size, ForKind::kThreadBinding, n->body).get();
LOG(INFO) << "new_for->min " << new_for_node->min;
// Check failed: (tindex < type_table_.size() && type_table_[tindex].allocated_slots != 0) is false: Unknown type index 76391888

@wrongtest-intellif, do you have any thoughts?

However, when I try to instantiate new_for_node directly, like this:
node pointer do not take ownership of objects. it seems your new_for_node referenced object is already deconstructed in the previous line, with dangling pointer left.

However, when I try to instantiate new_for_node directly, like this:

node pointer do not take ownership of objects. it seems your new_for_node referenced object is already deconstructed in the previous line, with dangling pointer left.

thanks, exactly, something relevant to the Ownership, now use For instead of ForNode* to take advantage of TVM ObjectRef management.

authors: LeiWang1999 tqchen wrongtest-intellif


text:
[DOC] Update documentation: JDK 1.7 -> 1.8

What is this PR for?
Zeppelin is built with JDK 1.8 since 0.7.1 as far as I know. But it is still 1.7 on installation documentation. Polina Marasanova pointed that out! Thanks!
This PR should be merged into master and 0.7.X in my opinion.
What type of PR is it?
Documentation
Questions:

Does the licenses files need update? NO
Is there breaking changes for older versions? NO
Does this needs documentation? NO

Hi, @tae-jun Thanks for the contribution. AFAIK,

Zeppelin is built with JDK 1.7 still for release binary.
0.7.1 is built with JDK 1.8 unintentionally.

will be appreciated if someone also verifies JDK version.

Oh sorry I didn't see the last comment here.
Then should I close this PR or just merge into only 0.7.1?

I think it's better build artifact using jdk7 on 0.7.2

I think we can close this PR. 0.7.2 would like to be built w/ JDK 7 according to the comment.

OK. Thanks for the review @1ambda!
I'm closing myself 😄

repo: apache/zeppelin

license_source: bigquery


text:
[ZEPPELIN-6002] Fix completer NPE

What is this PR for?
NPE occur when adding the driver specific SQL completions. Some driver(hive-jdbc-uber-2.6.5.0-292.jar in my case) does not implement method DatabaseMetaData.getDriverName() well and cause exception , then fail to initialize keywordCompleter.
Since it is optional, we should avoid such driver interfere  the default one, and log it for the profession
What type of PR is it?
Bug Fix
Todos

[ ] - Task

What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-6002
How should this be tested?

Strongly recommended: add automated unit tests for any new or changed behavior
Outline any manual steps to test the PR here.

Screenshots (if appropriate)

Questions:

Does the license files need to update?
Is there breaking changes for older versions?
Does this needs documentation?

@Reamer thanks for your help!

The SQLException can no longer be thrown by the getSqlKeywordsCompletions method, so the method signature must be adjusted.

authors: Reamer kevinjmh


text:
MD perf stats

added ns/day and mu s/step/atom metrics to MD logs
bumped jaxmd node default log level to info

pre-commit.ci autofix

repo: apax-hub/apax

license: MIT


text:
Add support for aufs to graphstorage.

This adds support for aufs as a graphstorage implementation. This
enables Kurma to work on Ubuntu 14.04 and 12.04.
The container stager has also been updated to default to automatically
detecting which driver to use, if one isn't explicitly defined.
A few updates have been made to the Ubuntu packer definitions for Ubuntu
14.04 and 12.04. On both, the cgroup-lite package was installed to
ensure all cgroups mounts are available on boot. Additionally, the 12.04
defintion will install the 3.13 kernel from Ubuntu trusty. By default,
12.04 used the 3.2 kernel, which is older than kernels typically
recommended for container workloads for full and stable functionality.
Fixes #33.
@alextoombs @mbhinder

Mostly added nits, LGTM

authors: krobertson mbhinder

repo: apcera/kurma


text:
CAS 4.1.1 throws bouncycastle cryptography exception

This is a 4.1.1 overlay. Tomcat 7.0.62
******************** Welcome to CAS ********************
CAS Version: 4.1.1
Java Home: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre
Java Vendor: Oracle Corporation
Java Version: 1.8.0_45
OS Architecture: x86_64
OS Name: Mac OS X
OS Version: 10.11.1
*******************************************************

This exception is thrown during TC start up and deployment attempt:
Error creating bean with name 'loginFlowStateTranscoder' defined in ServletContext resource [/WEB-INF/cas-servlet.xml]: Cannot resolve reference to bean 'loginFlowCipherBean' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'loginFlowCipherBean' defined in ServletContext resource [/WEB-INF/cas-servlet.xml]: Cannot create inner bean 'org.cryptacular.generator.sp80038a.RBGNonce#54146081' of type [org.cryptacular.generator.sp80038a.RBGNonce] while setting bean property 'nonce'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.cryptacular.generator.sp80038a.RBGNonce#54146081' defined in ServletContext resource [/WEB-INF/cas-servlet.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.cryptacular.generator.sp80038a.RBGNonce]: Constructor threw exception; nested exception is java.lang.SecurityException: class "org.bouncycastle.util.Arrays"'s signer information does not match signer information of other classes in the same package

Looks like a dependency conflict of bcprov library. Closing...

Hi dima767. How do you resolve this issue? I face the same problem.

repo: apereo/cas


text:
Fix correct mapping account disable view 3040

Cas Configuration:

CAS v5.1.5
cas.pm.authn.enabled=true

Use Case:
When Authentication service raises AccountPasswordMustChangeException, CAS maps the error to view - CasWebflowConstants.VIEW_ID_MUST_CHANGE_PASSWORD . At this state, if PasswordChangeAction returns false or raises exception, CAS incorrectly shows Account Disabled page instead of 'CasWebflowConstants.VIEW_ID_MUST_CHANGE_PASSWORD' with error message.
Cause:
PasswordManagementWebflowConfigurer configures 3 views for Error event. Hence, whenever action returns error event, the flow shows AccountDisabled view.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: code-4-fun:x: Nalawade, Devendra | Deven | ESDNalawade, Devendra | Deven | ESD seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


text:
renovatebot(deps): update dependency org.codehaus.jackson:jackson-mapper-asl to v1.9.13-atlassian-2

This PR contains the following updates:

Package
Update
Change

org.codehaus.jackson:jackson-mapper-asl (source)
patch
1.9.13 -> 1.9.13-atlassian-2

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
As this PR has been closed unmerged, Renovate will now ignore this update (1.9.13-atlassian-2). You will still receive a PR once a newer version is released, so if you wish to permanently ignore this dependency, please add it to the ignoreDeps array of your renovate config.
If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.


text:
Adding code maintainability badge

Dear Contributors,
As professional developers, you probably must be well aware of the meaning and importance of code maintainability! It expresses how difficult and risky it is to change the code. Maintainability is affected by a variety of low-level code quality attributes, like source code metrics, code duplications, clone smells, coding issues, and so on. Being able to measure it is crucial for keeping it at desired level.
We, at FrontEndART, have developed advanced algorithms based on benchmarks and quality models that allow us to quantify and track changes of code maintainability. The approach called "Probabilistic Software Quality Model" is based on the research conducted at the Software Engineering Department of University of Szeged (Hungary): https://ieeexplore.ieee.org/document/6080791.
We are excited to allow open source communities to use our tool called QualityGate (https://www.quality-gate.com), which incorporates these methods, enabling them to track their projects' maintainability.
If you agree that measuring, monitoring and promoting the maintainability of your project's code base adds a value to it, please accept this pull-request, which just adds a new badge to your project that shows its actual level of maintainability.
If you have further questions or comments, please do not hesitate to contact us at info@frontendart.com.
Best regards,
FrontEndART team

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Dear Software Developer(s)!
It seems that you have closed our pull request in order to deny placing our source-code maintainability.
Our company, FrontEndART Software Ltd. strives to achieve the highest quality in the field of software development, so we are eagerly awaiting your feedback.
Regards,
FrontEndART Development Team


text:
remove deprecated methods

See https://github.com/apereo/cas/pull/5211/files


text:
Сandles go outside the area.

Thanks a lot for this #426 .
But in the new version I've found a new problem.
Sometimes a candle goes outside the area.

Try this data
[[1553250600000,[0.20419999999999999,0.2051,0.20399999999999999,0.2041]],[1553252400000,[0.2041,0.20419999999999999,0.20349999999999999,0.2039]],[1553254200000,[0.2039,0.20419999999999999,0.20330000000000001,0.20399999999999999]],[1553256000000,[0.2041,0.20549999999999999,0.20349999999999999,0.20480000000000001]],[1553257800000,[0.20469999999999999,0.20519999999999999,0.2031,0.20430000000000001]],[1553259600000,[0.20430000000000001,0.20569999999999999,0.2039,0.20469999999999999]],[1553261400000,[0.2046,0.20530000000000001,0.20369999999999999,0.20369999999999999]],[1553263200000,[0.20369999999999999,0.2049,0.20230000000000001,0.2044]],[1553265000000,[0.2044,0.20549999999999999,0.2039,0.2051]],[1553266800000,[0.20499999999999999,0.20699999999999999,0.20469999999999999,0.20680000000000001]],[1553268600000,[0.20680000000000001,0.20730000000000001,0.2059,0.20710000000000001]],[1553270400000,[0.20710000000000001,0.20860000000000001,0.2056,0.20699999999999999]],[1553272200000,[0.20699999999999999,0.2072,0.20630000000000001,0.20699999999999999]],[1553274000000,[0.2069,0.20830000000000001,0.20660000000000001,0.20780000000000001]],[1553275800000,[0.20780000000000001,0.20830000000000001,0.2069,0.2072]],[1553277600000,[0.2072,0.2074,0.20660000000000001,0.2069]],[1553279400000,[0.20699999999999999,0.20710000000000001,0.20619999999999999,0.20619999999999999]],[1553281200000,[0.20630000000000001,0.2072,0.20580000000000001,0.20649999999999999]],[1553283000000,[0.20660000000000001,0.20699999999999999,0.20549999999999999,0.20630000000000001]],[1553284800000,[0.20619999999999999,0.20669999999999999,0.20569999999999999,0.20660000000000001]],[1553286600000,[0.2064,0.2074,0.20599999999999999,0.20699999999999999]],[1553288400000,[0.20699999999999999,0.20799999999999999,0.20649999999999999,0.2072]],[1553290200000,[0.20699999999999999,0.20730000000000001,0.20599999999999999,0.20630000000000001]],[1553292000000,[0.20630000000000001,0.2069,0.2054,0.2059]],[1553293800000,[0.2059,0.20619999999999999,0.20519999999999999,0.20599999999999999]],[1553295600000,[0.20610000000000001,0.20630000000000001,0.20530000000000001,0.20549999999999999]],[1553297400000,[0.2054,0.2064,0.2054,0.2054]],[1553299200000,[0.2054,0.2059,0.2026,0.20280000000000001]],[1553301000000,[0.20280000000000001,0.2039,0.20250000000000001,0.20349999999999999]],[1553302800000,[0.2036,0.20399999999999999,0.20300000000000001,0.20349999999999999]],[1553304600000,[0.20369999999999999,0.20530000000000001,0.20349999999999999,0.20469999999999999]],[1553306400000,[0.20480000000000001,0.20519999999999999,0.20399999999999999,0.20499999999999999]],[1553308200000,[0.20519999999999999,0.20530000000000001,0.2031,0.2034]],[1553310000000,[0.2034,0.20369999999999999,0.19589999999999999,0.19989999999999999]],[1553311800000,[0.1996,0.20119999999999999,0.19839999999999999,0.20080000000000001]],[1553313600000,[0.20080000000000001,0.20200000000000001,0.19980000000000001,0.20080000000000001]],[1553315400000,[0.20100000000000001,0.20150000000000001,0.19939999999999999,0.2001]],[1553317200000,[0.20019999999999999,0.20130000000000001,0.19989999999999999,0.20119999999999999]],[1553319000000,[0.20119999999999999,0.20280000000000001,0.2011,0.20230000000000001]],[1553320800000,[0.20219999999999999,0.2024,0.19969999999999999,0.2011]],[1553322600000,[0.2011,0.20300000000000001,0.20080000000000001,0.2024]],[1553324400000,[0.2024,0.2026,0.2011,0.2016]],[1553326200000,[0.2019,0.20280000000000001,0.2016,0.2026]],[1553328000000,[0.2026,0.20300000000000001,0.20219999999999999,0.2024]],[1553329800000,[0.2024,0.2026,0.2019,0.20250000000000001]],[1553331600000,[0.20250000000000001,0.2026,0.2016,0.2016]],[1553333400000,[0.2016,0.20200000000000001,0.2014,0.2019]],[1553335200000,[0.2019,0.20200000000000001,0.19850000000000001,0.20069999999999999]],[1553337000000,[0.2006,0.2014,0.20000000000000001,0.20130000000000001]],[1553338800000,[0.20130000000000001,0.20130000000000001,0.2011,0.20130000000000001]]]

Fixed in 3.6.4

authors: junedchhipa molotoksoftware


text:
Add an API failure e2e test

Add an e2e test where the API responds with a non-2XX code and the Airnode responds by calling fail()

@bbenligiray - we actually have this: the following airnode-node e2e test calls fail and reports the failed request API status code (404 in this case) on-chain:
https://github.com/api3dao/airnode/blob/c77e843e5c060a6d1400d42f56e5b8dae9645f63/packages/airnode-node/test/e2e/request-status.feature.ts#L10-L47

Indeed, thanks for checking

authors: bbenligiray dcroote


text:
Confirm README has all example config keys in it

Resolves:

Parse the README file and expect all configuration keys of the airseeker.example.json to be present.

Closes #42

I've reverted the README changes, implemented your regex based search and mocked the readFileSync calls so the config loader will work with the example config without require extra arguments :) @Siegrift


text:
PoC Airseeker fixes for beacon sets

https://api3workspace.slack.com/archives/C040G0W7RH9/p1683128039798789?thread_ts=1683100578.835749&cid=C040G0W7RH9
@acenolaza
This branch splits out the main component of the single-beacon update function into a discrete function. It then calls that function for every beacon inside a beaconset to try and update those beacons first before attempting to update the parent beacon set. This prevents a scenario where Airseeker tries to update a beacon set using off-chain data but the transaction fails because the on-chain data is stale/doesn't match.
This branch also uses the aggregation function to aggregate the timestamps (median), which is what the contract does (a relatively recent change).
LMK if you need the config file on Keybase.
For efficiency we probably need to make the updateBeacon function accept a "checkOnly" arg, run through the feeds and if more than one needs to be updated, use multicall otherwise single update.

I'm pretty sure that updating the beaconSet constituents was the original plan but because it was too expensive we ended up not doing it. @bbenligiray or @amarthadan might remember

🙈
It looks like the function that enabled updating a beacon set with signed data was removed from airnode-protocol-v1. In other words, in the current implementation that only way of updating a beacon set appears to be by first updating the constituents. AFAIK this is now the approach.
Assuming the above is correct, it then becomes a question of how and when those child data feeds should be updated; multicall, definitely, but do we update them with their existing-configured update triggers or do we perhaps do a more advanced check where we try to determine if updating a child would have a material effect on the parent?

I'm quite confused about this check 😁 This is the same check that is causing the revert mentioned above and we are trying to update the beaconSet beacons in order to get past that require statement in the contract. So wouldn't this check in Airseeker prevent it from updating the beaconSet beacons causing the same end result of the beaconSet not getting updated because of stale beacons?

The median check for timestamps was discussed a few weeks (?) back. In the original implementation (see here) it was an average of the submitted timestamps. Naturally the average would never match an equality check, so there was a greater-than check instead. Now that it's a median the check has been replaced with an equality check.
The timestamp equality check often fails because of an underlying issue; the child beacons on chain may not be up to date. Airseeker does a beaconset update check based on off-chain values (in the Airseeker cache), but the update function on the contract uses on-chain data, which may be stale. Therefore it is necessary to check that the underlying beacons on chain are fresh before attempting a parent update.
In the original update function, where we didn't care about the on-chain child data, this was fine... but now we update with only the beaconIds, relying on the on-chain data.

I would definitely like to run this locally to be able to debug the code.
I'll pause work on this then and send you the config file on Keybase :)

It looks like the function that enabled updating a beacon set with signed data was removed from airnode-protocol-v1. In other words, in the current implementation that only way of updating a beacon set appears to be by first updating the constituents. AFAIK this is now the approach.
Assuming the above is correct, it then becomes a question of how and when those child data feeds should be updated; multicall, definitely, but do we update them with their existing-configured update triggers or do we perhaps do a more advanced check where we try to determine if updating a child would have a material effect on the parent?
Like maybe iterate through children, for every child check if the beaconset should be updated with all feeds excluding that child, if no, update it as part of the main update.

Oh I see what you mean. Thanks for adding more details and you are right. For updating a beaconSet it is now expected that most beacons are up-to-date but I'm still not sure who/how/when should those beacons be updated. I'm now thinking that this might be reason behind the decision to update the beaconSet beacons but I might have missed that discussion 🤔

In the original update function, where we didn't care about the on-chain child data, this was fine... but now we update with only the beaconIds, relying on the on-chain data.

👍🏻
I'll pause work on this then and send you the config file on Keybase :)
🙏🏻

The plan was to update the underlying Beacons and then the Beacon set in a single multicall, this was only discussed on Slack during the audit revisions. Let me know if we need to do a call about this.

Closed as changed integrated into the rate limiting fixes branch.

authors: acenolaza aquarat bbenligiray


text:
Improve --allow-net flag

cli: propagate --allow-net flag
sink: --allow-net="" allows any host
Summary
This change ensures that the --allow-net flag works in environments were
changing the command line arguments is not feasible/recommended (e.g.
docker containers).
Fix #312
release: cli, sink-{console, mongo, parquet, postgres, webhook}
Summary
cli: v0.4.2
sink-console: v0.4.2
sink-mongo: v0.5.2
sink-parquet: v0.4.2
sink-postgres: v0.5.3
sink-webhook: v0.4.2

Current dependencies on/for this PR:

main

PR #313   👈

This stack of pull requests is managed by Graphite.

repo: apibara/dna


text:
swaggerSecurity : json response

I cannot find a way to return a json response when my swaggerSecurity blocks the request :
    app.use(middleware.swaggerSecurity({
        AdminSecurity: function (req, def, key, callback) {
            if (key !== 'admin') {
                let error = new Error('Unauthorized admin');
                error.statusCode = 401;
                error.headers = {'Content-Type': 'application/json'};
                callback(error);
            } else {
                callback();
            }
        },
        UserSecurity: function (req, def, key, callback) {
            if (key !== 'user') {
                let error = new Error('Unauthorized user');
                error.statusCode = 401;
                error.headers = {'Content-Type': 'application/json'};
                callback(error);
            } else {
                callback();
            }
        }
    }));

I can see in the logs it uses finalhandler :
Thu, 18 May 2017 11:51:08 GMT finalhandler default 401

All swagger-tools middleware send errors downstream via next(err).  This is the convention for Connect-based middleware.  If you want to handle these errors, by turning them into JSON responses, you need to provide your own error handler.  This has come up a few times.

okay thanks i'll check this out.

authors: gnujeremie whitlockjc

license: mit


text:
Create or update during import of products

Currently when we try to import an existing product it will just fail with an alert, saying that it already exist.
I belive that the usual approach is to update it when it already exists, so I would love to see the option to update existing products.
With this feature I will be able to create a workflow (git based) to update the products in an automated way. To achieve the same with the current approac (apigeecli products updat) can be harder using other CLI tools (bash, powershell...)

Is the flow you are describing have a file with one or more API Products and you wish to import (create or update as needed) them?

Yes, I would like to create a file with one or more API products (similar to the one generates with the "product export" command), when I run the import command I wish that everything will be created or updated, as needed)

Unfortunately the API does not support upsert. This will double the number of API calls to the control plane. For large data sets, it can affect the quota.
That said, I can see the usefulness of this feature for smaller datasets.

authors: peruzzof srinandan

repo: apigee/apigeecli


text:
🛑 Mynemo is down

In 5b4a3eb, Mynemo (https://mynemo.umt.edu.my) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mynemo is back up in 6bc2454.

repo: apikmeister/umt-web-uptime


text:
Design API Rating field and widget

Design functionality for consumers to be able to rate API Backends on a numeric scale via a simple widget.
Definition of done

[x] Brainstorm ideas for rating.

[x] Look for and document existing examples of rating applications etc.

[x] Create design document for the rating functionality. (This may include user flow, schema etc.)
[x] Create wireframes for rating UI.

@elnzv Can you provide a status provide and commit any work in progress, even design pictures, to Github?

added wireframes to docs repo:
https://github.com/apinf/docs/blob/master/docs/design/%23471_rating_field_widget.png

@bajiat please review, if you have any comments, let me know.

@elnzv I would suggest that you would indicate your own preference for the three options and also explain the pros and cons of each. Also, please indicate how a user can  rate the APIs or vote for them in each.

@bajiat, added suggested information

@elnzv Excellent additions! You can perhaps still say explicitly which one do you recommend (I quess it's the one with stars) and then close the issue.

@bajiat, already done this - next to Stars' title my comment.

@elnzv Ok, I managed to somehow ignore that and noticed only the visual feedback and the pros and cons. Then everything's just fine, go ahead and close the issue.

authors: bajiat brylie elnzv

repo: apinf/api-umbrella-dashboard


text:
🛑 Gitea is down

In 8e33732, Gitea (https://gitea.adathor.com) was down:

HTTP code: 502
Response time: 605 ms

Resolved: Gitea is back up in 476a29b after 6 minutes.

repo: apinter/OSC-mon


text:
add graph transformations during protocol selection

Protocol selection is currently structure-preserving: once a PDG is generated, protocol selection only considers the same PDG. It maps PDG nodes to protocols, but does not consider other possible PDGs for the same surface program. This eliminates other possible protocols that we can synthesize; for example, some surface programs can be efficiently completely using MPC. This protocol will not be considered during protocol selection because currently the code the generates a PDG from the surface program creates a more fine-grained PDG --- it splits expressions at downgrade boundaries, etc.
One possible way to do this is by considering local graph rewrites that pattern match on parts of a graph. Protocol selection then has to be refactored since the nodes in the search space are no longer maps for the same initial PDG but rather a pair of a possible PDG for the surface program and a partial map from nodes in the possible PDG to protocols.

Not going to do this. ANF translation generates the largest possible graph, and selecting protocols for this graph is as fine-grained as possible. There might be hypothetical reasons for opting for coarse-grained selection, but in practice it doesn't seem like it matters.

repo: apl-cornell/viaduct


text:
JSON error on /containers/create

Hello,
I'm having the following issue:
  modem Sending: { path: 'http://localhost:2375/containers/create?Image=library%2Fjava%3Aopenjdk-8-jre&Cmd=java&Cmd=-Xmx1024M&Cmd=-Xms1024M&Cmd=-XX%3AMaxPermSize%3D128M&Cmd=-jar&Cmd=%2Fserver.jar&Cmd=nogui&Memory=1024M&AttachStdin=true&OpenStdin=true&ExposedPorts=',
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'Content-Length': 214 },
  key: undefined,
  cert: undefined,
  ca: undefined,
  socketPath: '/var/run/docker.sock' } +1s
  modem Received: json: cannot unmarshal string into Go value of type int64

I'm creating the docker container using the following code:
        docker.createContainer
          Image: image
          Cmd: ['java', "-Xmx#{memory}M", "-Xms#{memory}M", '-XX:MaxPermSize=128M', '-jar', "/server.jar", 'nogui']
          Memory: memory + 'M'
          AttachStdin: true
          OpenStdin: true
          # Port binding pre-something
          ExposedPorts: { "25565/tcp": {} }
        , (err, container) =>
          if err then return cry err
          debug 'Container created'
          yell(container)

Is there a way to fix this problem?
Thank you.

The Memory attribute is in bytes when using the API and does not support the same shorthand as the CLI.
Try this instead:
  // ...
  Memory: memory * 1024 * 1024,
  // ...

Thanks. It worked some time ago so I assume it was removed in a new version.

authors: casdr rmg

repo: apocas/dockerode


text:
Update DB2 version to 11.5.7

Describe the solution you'd like
I would like to use newer DB2 version.

Based on https://www.ibm.com/docs/en/cloud-paks/1.0?topic=platform-pre-installation-requirements IPM supports cn2


text:
Isn't cache supposed to work with GraphQL Subscriptions?

I found that Normalized Cache does not work with GraphQl Subscriptions (opened via websockets), and I didn't find anything in the apollo-android code that would prove the opposite.
Could you confirm it and probably clarify the reasons why it was designed so?
I found a workaround for that but this should probably be done by default:
Rx2Apollo.from(call)
            .flatMapSingle((Response<D> response) -> Rx2Apollo
                .from(apolloClient.apolloStore().writeAndPublish(subscription, response.data()))
                .onErrorReturnItem(false) // no need to cancel subscription because of the failed cache update
                .map($ -> response))

Thanks!

Currently subscriptions doesn't support normalized cache. Not sure if it make sense to add such support as subscriptions represents live queries via web socket connection.

Thanks for the confirmation!
IMHO it makes perfect sense to utilize normalized cache here, as it's the most common use case of websockets: delivery of some updates initiated by the backend to the app.
I'm not sure what to do if CacheKeyResolver produces NO_CACHE_KEY, but for the data which we can calculate cache key for (using id  or smth), why wouldn't we want to put it into the cache?

hm, maybe you are right.
So you want to be able get cached response for the subscription before running a subscription?

@sav007 There is a pattern that teams widely using. Generally focus is to use cache as the source of the data and use subscriptions to refill that data. More about this approach in this blog:
https://medium.com/@wtr/data-query-patterns-for-graphql-clients-af66830531aa#1150
In Apollo-client (js) users can simply use subscribeToMore to get more data

@sav007 We have investigated having interceptor layer attached to subscriptions. Are you open to accept Pull requests on this or you do think that this is bad idea?
I have seen so many workarounds for lack of cache on subscriptions and I think that there should be at least the ability to attach this extra interceptor for developers who would like to use cache as a source of truth. Without that, it is hard to work with cache enabled app.
Let's imagine that we have a query cached on some separate activity. Now we subscribed to receive new results that are pushed directly to UI (which is Kinda antipattern on it's own). Then we go back to previous view and go back to original view again. Since results are in the cache we get old results. Most of the developers at this point are really confused and simply do:

Things can go even worse as the subscription will now deliver new results.
There are also problems with race conditions and deduplication of data in cache (but that is kinda usual thing)
IMHO There are two ways to solve this problem:

Document actual patterns for working with subscriptions in Android
(Developers commit from js-land will have different options there)
Enable normalized cache  for subscriptions
Come up with something like subscribeToMore that is available in js

@wtrocki  do you know if queries and subscriptions on JS share the same root cache key?
Right now our normalized cached for queries has QUERY_ROOT as root cache key, for instance:
  "1002" : {
    "__typename" : Human
    "id" : 1002
    "name" : Han Solo
  }

  "QUERY_ROOT" : {
    "hero({"episode":"NEWHOPE"})" : CacheRecordRef(2001)
  }

  "1003" : {
    "__typename" : Human
    "id" : 1003
    "name" : Leia Organa
  }

  "1000" : {
    "__typename" : Human
    "id" : 1000
    "name" : Luke Skywalker
  }

  "2001" : {
    "__typename" : Droid
    "id" : 2001
    "name" : R2-D2
    "friends" : [
      CacheRecordRef(1000)
      CacheRecordRef(1002)
      CacheRecordRef(1003)
    ]
  }

So should the subscription share the same root cache key as query?
subscription TestSubscription($episode: Episode!) {
  hero("episode": $episode) {
    ...
  }
}

Actually never mind, after investigation our QUERY_ROOT  is a root for all queries (even mutations). So should be the same for subscription.
Now do you think having 2 fetch policies makes sense for the subscription:

NETWORK_ONLY - bypass cache (will be a default policy)
CACHE_AND_NETWORK - first hit the cache then network

do you know if queries and subscriptions on JS share the same root cache key?

There are couple cache implementations in JS. The Apollo - InMemoryCache uses the following structure:
{
  Query: {},
  Mutation: {},
  Subscriptions: {},
   ... cachedData
}

There are two ways to work with subscriptions:

SubscribeToMore as part of the query
Direct subscription call (IMHO less popular)

Subscribe to more works as follows:

Puts normalized data into cache
Let's user provide update method that can add items to query.
2.1 Alternative refetchQueries can be executed
There are numerous community libraries that help the developer to provide query updates

So should the subscription share the same root cache key as query?

Amazing question. Regular subscription may not, but subscribeToMore method can enable that.

Now do you think having 2 fetch policies makes sense for the subscription

I do think that subscriptions should simply enable saving data to the cache (when using normalized cache option). Then developers should be able to specify queries they want to list this new changes.
This blog post from my colleague describes the subscription/mutation update problem:
https://dev.to/aerogear/automatically-update-apollo-cache-after-mutations-20n7
However there could be another approach to get it simply by subscribing to the data again you could get first results from what was already cached - but this is also causing some duplication issues between query and subscription. Generally, problem is not trivial and it will require some discussion basing on how Android developers would expect to work with the live data.
I do think that the best way to make subscriptions work for Android would be to simply add ability to connect subscription with the query. Subscription will simply provide more data to query using incremental fashion and also update the query cache

Cache support is a must for subscriptions. Default policy here for after CRUD ops is to simply invalidate the cache for a given key (using server side pagination and sorting).
Now... that being said, when subscription data arrives (say a new record) same policy would be needed, but, alas, no access to cache.
Long story short... I've resorted to 'network-only' fetches after a subscription fires to keep data consistent in the UI :/

authors: pdoria sav007 wtrocki yankeppey

repo: apollographql/apollo-android


text:
How to implement and plugin a interceptor/filter for the client?

How can I implement an interceptor/filter for a GraphQL Android client? How can I configure the client instance to use it. In the interceptor, I need to access both errors in the GraphQL response and HTTP headers.
The iOS client has HTTPNetworkTransportDelegates for this purpose.

It's actually a lot easier in Android, you should be able to use an ApolloInterceptor for this.

@designatednerd Thanks for the pointer. I see that InterceptorResponse passed to Callback#onResponse contains both the parsed GraphQL response and the HTTP response. I guess that serves the need.


text:
[Gradle Plugin] make generating operation ids part of the task graph

Closes #2455
This pull requests adds the possibility for users to wire their own GenerateOperationIdsTask with setGenerateOperationIdsTaskProvider
. For an exemple:
abstract class GenerateCustomOperationIdsTask: ApolloGenerateOperationIdsTask() {
  override fun generateOperationOutput(operationList: OperationList): OperationOutput {
    return operationList.map {
      // use the operation name as Id
      it.name to it
    }.toMap()
  }
}

configure<ApolloExtension> {
  onCompilationUnit {
    val task = tasks.register("generate${name.capitalize()}OperationIds", GenerateCustomOperationIdsTask::class.java)
    setGenerateOperationIdsTaskProvider(task)
  }
}

To do this, I had to split the main task in three:

generate${variant}${service}ApolloIR: takes the schema and GraphQL files as input and generates ir.json and operationList.json as output
generate${variant}${service}ApolloOperationIds (or the task registered by the user: takesoperationList.json  as input and generates oprationOutput.json  as output
generate${variant}${service}ApolloSources: takes ir.json and operationOutput.json  as input and generates the models

@sav007 Regarding performance, below are a few build scans using 24k lines of Github queries resulting in a 10MB ir.json (and doing rm -rf build and changing the plugin version in between builds):
With the IR serialisation (this branch):

https://scans.gradle.com/s/rmfibi3vrpeog -> 6.9s
https://gradle.com/s/fdrw7h7rzg6im -> 7.1s
https://gradle.com/s/sba6i4iaswbqw -> 7.2s

Without (master):

https://scans.gradle.com/s/a2n5pyv5jgufe -> 6.5s
https://scans.gradle.com/s/g4ciudzqg5zjw -> 5.4s
https://scans.gradle.com/s/y73mhrkr3k3h4 -> 6.5s

There is a performance impact in the of order of 7-8%. Of course it depends a lot of factors like the warmness of the gradle daemon and stuff but the above should be a good approximation.
Serializing ir.json takes ~100ms (same for deserializing) so they account for ~200ms in the ~500ms slowdown, the rest being the bigger task graph I guess, time checking the up-to-date-ness of the inputs and computing checksum?
0.5s might not be a huge thing in the grand scheme of Android builds but it might be worth keeping everything as a single task and relying on bumping version as we currently do. Let me know what you think. (Also ping @DSteve595 for awareness.)

I updated this PR to keep everything in a single task and skip serialization. Sample usage is in the (edited) original post. Let me know what you think.

Does operationDescriptorList need to be a List? Does a Set make more sense, since there's no inherent ordering?

Does operationDescriptorList need to be a List? Does a Set make more sense, since there's no inherent ordering?

I guess it can even be a Collection. Let me try

I'd like to make a release this week. If there's no additional comments, I'll merge this tomorrow so we have some time test the snapshots until a release at the end of the week.


text:
chore(deps): update dependency @vue/test-utils to v2.4.6

This PR contains the following updates:

Package
Change
Age
Adoption
Passing
Confidence

@vue/test-utils
2.4.2 -> 2.4.6

Release Notes

vuejs/test-utils (@vue/test-utils)
v2.4.6
Compare Source
What's Changed

Fix/circular references in props cause maximum call stack size exceeded by @Evobaso-J in https://github.com/vuejs/test-utils/pull/2371
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2374
docs: setup the translation helper by @Jinjiang in https://github.com/vuejs/test-utils/pull/2373
chore: translate translation sync message in french by @cexbrayat in https://github.com/vuejs/test-utils/pull/2377
docs: synchronize the french docs by @cexbrayat in https://github.com/vuejs/test-utils/pull/2378
chore(deps): update dependency vite to v5.2.2 by @renovate in https://github.com/vuejs/test-utils/pull/2376
chore(deps): pin dependency vitepress-translation-helper to 0.1.3 by @renovate in https://github.com/vuejs/test-utils/pull/2379
chore(deps): update dependency typescript to v5.4.3 by @renovate in https://github.com/vuejs/test-utils/pull/2380
chore(deps): update dependency vitepress-translation-helper to v0.2.0 by @renovate in https://github.com/vuejs/test-utils/pull/2381
chore: update vitepress-translation-helper by @Jinjiang in https://github.com/vuejs/test-utils/pull/2382
chore(deps): update dependency vitepress to v1.0.0 by @renovate in https://github.com/vuejs/test-utils/pull/2383
chore(deps): update dependency vitepress-translation-helper to v0.2.1 by @renovate in https://github.com/vuejs/test-utils/pull/2384
fix: update attachTo type in MountingOptions interface by @taku-y-9308 in https://github.com/vuejs/test-utils/pull/2375
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2388
docs(api): fix typo in attachTo anchor tag within isVisible by @matusekma in https://github.com/vuejs/test-utils/pull/2351
change vm to always provide global property by @taku-y-9308 in https://github.com/vuejs/test-utils/pull/2386
chore(deps): update dependency rollup to v4.13.1 by @renovate in https://github.com/vuejs/test-utils/pull/2389
chore(deps): update dependency reflect-metadata to v0.2.2 by @renovate in https://github.com/vuejs/test-utils/pull/2391
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2393
chore(deps): update dependency vite to v5.2.8 by @renovate in https://github.com/vuejs/test-utils/pull/2396
docs: fix missing equal sign by @w2xi in https://github.com/vuejs/test-utils/pull/2398
fix: renderStubDefaultSlot with scoped slots by @cexbrayat in https://github.com/vuejs/test-utils/pull/2397
docs(api): fix missing chars by @w2xi in https://github.com/vuejs/test-utils/pull/2399
docs: use innerHTML in teleport cleanup by @brc-dd in https://github.com/vuejs/test-utils/pull/2403
feat: Added dynamic return for element getter by @nandi95 in https://github.com/vuejs/test-utils/pull/2406
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2407
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2408
doc(api): fix missing char by @w2xi in https://github.com/vuejs/test-utils/pull/2410
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2412
chore: use node v18 on netlify by @cexbrayat in https://github.com/vuejs/test-utils/pull/2416
fix(stubs): avoid warning on normalized props with Vue v3.4.22 by @cexbrayat in https://github.com/vuejs/test-utils/pull/2413
chore: use the packageManager field from package.json in github action by @cexbrayat in https://github.com/vuejs/test-utils/pull/2417
chore(deps): update pnpm to v9 by @renovate in https://github.com/vuejs/test-utils/pull/2415
chore(deps): update all non-major dependencies to v3.4.23 by @renovate in https://github.com/vuejs/test-utils/pull/2418
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2419
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2420
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2421
Update index.md to fix typo and clarify get vs find behavior by @KatWorkGit in https://github.com/vuejs/test-utils/pull/2422
fix: set global provides before running vue plugins by @danielroe in https://github.com/vuejs/test-utils/pull/2423
ci: add build on node v22 by @cexbrayat in https://github.com/vuejs/test-utils/pull/2424
chore(deps): update all non-major dependencies by @renovate in https://github.com/vuejs/test-utils/pull/2426
chore(deps): update dependency unplugin-vue-components to v0.27.0 by @renovate in https://github.com/vuejs/test-utils/pull/2427
chore(deps): update dependency @types/node to v20.12.8 by @renovate in https://github.com/vuejs/test-utils/pull/2429
Fix/issue 2319 throw first error thrown during mount by @taku-y-9308 in https://github.com/vuejs/test-utils/pull/2428

New Contributors

@Jinjiang made their first contribution in https://github.com/vuejs/test-utils/pull/2373
@taku-y-9308 made their first contribution in https://github.com/vuejs/test-utils/pull/2375
@matusekma made their first contribution in https://github.com/vuejs/test-utils/pull/2351
@w2xi made their first contribution in https://github.com/vuejs/test-utils/pull/2398
@brc-dd made their first contribution in https://github.com/vuejs/test-utils/pull/2403
@KatWorkGit made their first contribution in https://github.com/vuejs/test-utils/pull/2422

Full Changelog: https://github.com/vuejs/test-utils/compare/v2.4.5...v2.4.6
v2.4.5
Compare Source
What's Changed

feat: add teleport stub possibility, https://github.com/vuejs/test-ut… by @blizzardKv in https://github.com/vuejs/test-utils/pull/2336
fix(findComponent): Use correct vm for stubbed component with selector by @freakzlike in https://github.com/vuejs/test-utils/pull/2327
fix(teleport.md): fix missed "global" key, https://github.com/vuejs/t… by @blizzardKv in https://github.com/vuejs/test-utils/pull/2337
fix(vue-router.md): update highlights when mocking real router by @dmoyadev in https://github.com/vuejs/test-utils/pull/2340
fix(deps): update dependency vue-component-type-helpers to v2 by @renovate in https://github.com/vuejs/test-utils/pull/2358
fix: Allow access to nested computed values (fix #2196) by @Evobaso-J in https://github.com/vuejs/test-utils/pull/2356
docs: add mention of enableAutoDestroy replacement by @strokirk in https://github.com/vuejs/test-utils/pull/2344

New Contributors

@blizzardKv made their first contribution in https://github.com/vuejs/test-utils/pull/2336
@dmoyadev made their first contribution in https://github.com/vuejs/test-utils/pull/2340
@strokirk made their first contribution in https://github.com/vuejs/test-utils/pull/2344
@Evobaso-J made their first contribution in https://github.com/vuejs/test-utils/pull/2356
@qmonmert made their first contribution in https://github.com/vuejs/test-utils/pull/2364

Full Changelog: https://github.com/vuejs/test-utils/compare/v2.4.4...v2.4.5
v2.4.4
Compare Source
What's Changed

fix: ignore prototype methods when using setData on objects by @Haberkamp in https://github.com/vuejs/test-utils/pull/2265
fix: always load cjs bundle in node environment by @danielroe in https://github.com/vuejs/test-utils/pull/2269
fix: experimentalVmThreads is now pool=vmThreads by @cexbrayat in https://github.com/vuejs/test-utils/pull/2275
feat: respect devtools definition by @webfansplz in https://github.com/vuejs/test-utils/pull/2311

New Contributors

@ArtemTropanets made their first contribution in https://github.com/vuejs/test-utils/pull/2267
@Haberkamp made their first contribution in https://github.com/vuejs/test-utils/pull/2265
@danielroe made their first contribution in https://github.com/vuejs/test-utils/pull/2269
@webfansplz made their first contribution in https://github.com/vuejs/test-utils/pull/2311

Full Changelog: https://github.com/vuejs/test-utils/compare/v2.4.3...v2.4.4
v2.4.3
Compare Source
What's Changed

types(setProps): setProps to Partial props by @pikax in https://github.com/vuejs/test-utils/pull/2241

Full Changelog: https://github.com/vuejs/test-utils/compare/v2.4.2...v2.4.3

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - "after 8am and before 4pm on tuesday" in timezone Etc/UTC.
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
Because you closed this PR without merging, Renovate will ignore this update (2.4.6). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

repo: apollographql/apollo-ios-dev


text:
Static Typing

@helfer do you want me to go through and setup typescript like we did with apollo-client?

@jbaxleyiii I think static typing would be nice to have, but I'm a bit torn. Apollo-client is essentially standalone, so the choice of going with typescript made sense. Because apollo-server relies heavily on graphql-js, which is written in flow, I don't think it would make sense to use typescript for it.
We could use flow for apollo-server, but then we'd have the client written in typescript and the server written in flow, which also isn't ideal.
I'm definitely open to using static typing, but because of the above I think it would have to be Flow, and not Typescript. Do you think the benefits of static typing in apollo-server will be worth adding another language to our stack?

@helfer fwiw, we found that graphql-js doesn't export flow definitions so where we are using it in apollo-client we went with typescript because the definitions were much more readily available. Flow also doesn't currently support exporting of definitions like typescript does.
I'm open to whatever though :+1:

Let me write a bit more code in JavaScript and then see what the equivalent
would look like in Typescript. Right now the whole implementation in the
vanilla-parser branch is down to about 10 lines of effective code (except
for tests), so it's not enough for a comparison.
On Thu, Mar 31, 2016 at 4:23 PM, James Baxley notifications@github.com
wrote:

@helfer https://github.com/helfer fwiw, we found that graphql-js
doesn't export flow definitions so where we are using it in apollo-client
we went with typescript because the definitions were much more readily
available. Flow also doesn't currently support exporting of definitions
like typescript does.
I'm open to whatever though [image: :+1:]
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/apollostack/apollo-server/issues/6#issuecomment-204171913

@helfer sounds great! Just wanted to offer help :)

Yeah, thanks, I really appreciate it!

@jbaxleyiii I've added some relatively intricate logic for mocking in the last few days, and I sometimes wished I had static typing. If you have some time next week to make a typescript branch, that would be great!

@helfer happily! It'll help me get a feel for what's happening as well so I can contribute!

awesome, thanks a lot!
On Sat, Apr 9, 2016 at 4:51 AM, James Baxley notifications@github.com
wrote:

@helfer https://github.com/helfer happily! It'll help me get a feel for
what's happening as well so I can contribute!
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/apollostack/graphql-tools/issues/6#issuecomment-207776927

@jbaxleyiii Any update on this?

@helfer sadly no 👎 It is still on my to-do list! With vacation and coming out to SF I haven't gotten to it yet. I'm hoping to finish it this weekend

No worries, I was just going through all the issues to see which ones I could close :)

Closing this since I don't think it's on our immediate agenda any more now that Apollo Server has been rewritten in TypeScript.

Are there any plans to make typings for this?

Yes, @pcarrier is converting things to TypeScript as we speak.

authors: helfer jbaxleyiii paralin

repo: apollostack/apollo-server


text:
Auto-Speak

The auto-speak check for AWS Polly seems to need some debugging. It stopped processing in some cases.

Model selection specific, probably missing a function call somewhere.

See #75

repo: appatalks/chatgpt-html


text:
spec pods: Clearify empty volume kind

The spec for the "empty" volume kind is unclear. See https://github.com/appc/spec/issues/183 for the issue/discussion around this.
Note: My change proposes the rather strong spec of: lifetime of the empty volume == lifetime of the pod
I feel that this makes the use case of "empty" more clear than specifying lifetime of the empty volume >= lifetime of the pod as was suggested in https://github.com/appc/spec/issues/183#issuecomment-98582304 However, I don't have a strong opinion around this, and would be happy to change what I wrote.

This clarification is needed to unblock some rkt work: https://github.com/coreos/rkt/issues/1040

:+1: Question of a volume lifetime seems to be dependent on #276 (define "pod exits"), so I'd say it's out of scope now.

LGTM. @thockin ?

@kibra can you rewrite your commit message please - Clearify --> Clarify

@jonboulle Fixed, thanks for the catch.

@jonboulle Ping. I'm not super happy with my language here, but I think it's a least a step forward. Let me know if there's something you think I should change.

@kibra One more tweak then LGTM

@jonboulle Thanks for the feed backup. I've updated my PR.

thanks!

authors: jonboulle kibra mpasternacki

repo: appc/spec


text:
Bug: /hpm update doesn't work after the first time

After the first time I update a /hpm package, if I try to update another package, the list of package update doesn't appear. If I restart Hain, it works.
An example in the gif: I know it was just one package to update, but the result is the same.

Edit:
After a restart Hain shows correctly this screen:

After updating, there is a note at the bottom of Hain saying to Restart Hain to take effect

I noticed, but why I can't see any other updates?

@jimbolimbo3 Yes this is a bug. and it was fixed at 38795fc7c49487b50157a1d82ac7d031a18436a1
but it isn't released yet. so i close this issue

authors: Braunson appetizermonster jimbolimbo3

repo: appetizermonster/hain