Patched DataFusion, Oct 30, 2024

This takes us up to Oct-30 SHA https://github.com/influxdata/arrow-datafusion/commit/497582906e826d3045e2c7b9d4ddb44ce6d42adf
It advances DF by adding these oct-15 to oct-30 commits: https://github.com/influxdata/arrow-datafusion/compare/399e8403d2fb5a058fb263bc2449dbc9d7529841...influxdata:arrow-datafusion:497582906e826d3045e2c7b9d4ddb44ce6d42adf
NOTE: this does not include:

the SPM update, which is the last change on oct-30: https://github.com/influxdata/arrow-datafusion/commit/f23360f1e0f90abcf92a067de55a9053da545ed2
the internal use of view types for array record batch processing: https://github.com/influxdata/arrow-datafusion/commit/2d7892b6060793e721ce1d66242f485656e0430a

Patches applied

Patches already fixed in future upstream commits:

Nov-3 = https://github.com/apache/datafusion/commit/85f92ef6be1d7364857a2c13fbb026d9e45406ea
Nov-11 = https://github.com/apache/datafusion/commit/be19afca4ca93cf7ae0305aafec10b29a8140a58
clippy updates (presumably these are a bunch of separate upstream commits)
SanityCheckPlan

I'm not sure when we can stop skipping the SanityCheckPlan. I'm unclear how it relates to the additional sort pushdown fixes, including a recent fix done 3 weeks ago: https://github.com/apache/datafusion/pull/13497

Patches still not fixed:

commit reverted due to CPU spinning bug (new)
This empty projection patch, since I only ever found these plans in iox-created influqxl LP.

patch: https://github.com/influxdata/arrow-datafusion/pull/48/commits/cb44b88ecd2a66256076287bbcd739277c56ddd8
iox issue: https://github.com/influxdata/influxdb_iox/issues/12407

Patches specific to our DF branch (no need for upstream fix):

bit_length(utf8view) patch: https://github.com/influxdata/arrow-datafusion/pull/48/commits/90423e20c148012ce70ad36e38456956cf7d5e70
we are keeping in the warn logging for the schema mismatch. (Upstream only returns error, or not, based on schema misalignment): our patch https://github.com/influxdata/arrow-datafusion/pull/48/commits/69d6118c055ff3549a7dd3d91d13d31292943f50
we are using an extra few bytes for the GroupedHashAggregateStream: https://github.com/influxdata/arrow-datafusion/pull/48/commits/50e1209c119261692d739afaf4ce509a93833ea4

tech debt to be fixed:

we are keeping in the warn logging for the schema mismatch. (Upstream only returns error, or not, based on schema misalignment): our patch https://github.com/influxdata/arrow-datafusion/pull/48/commits/69d6118c055ff3549a7dd3d91d13d31292943f50
I reverted/excluded the commit to turn on view types by default (for arrow processing):

we had errors for iox tests with existing parquet, which contained string value fields.

e.g. end_to_end_cases::cli::write_and_query, end_to_end_cases::cli::table::create_write_and_query.
The exact error thrown was an iox schema check. Even if this was updated to accept view types as valid => we had arrow cast errors where it kept attempting ot cast to string array (not view).
* I can guess this is due to our various iox codepoints where we map String fields to arrow's Utf8. I would rather not muck around with that, unless it's done separately.
* Additionally, setting schema_force_view_types=false feels fragile since it's nested in a various options. To be on the safe side, I would rather revert this commit for now.

we are using an extra few bytes for the GroupedHashAggregateStream: 89ae9bf

@alamb note that this is a new commit.
.

This empty projection patch, since I only ever found these plans in iox-created influqxl LP.

patch: https://github.com/influxdata/arrow-datafusion/commit/001865dd8803e4a1a53f31e770cb6a88b043e89b
iox issue: https://github.com/influxdata/influxdb_iox/issues/12407

@alamb note that this is a newly re-written commit, now that we advanced to the latest (on DF main) version of union_schema(). This is the remaining bit we patch to handle our iox-specific issue.

we are using an extra few bytes for the GroupedHashAggregateStream: 89ae9bf

@alamb note that this is a new commit.
.

This empty projection patch, since I only ever found these plans in iox-created influqxl LP.

patch: https://github.com/influxdata/arrow-datafusion/pull/48/commits/409ffada494bbfc92d35fe3736b015fa4722a4fd
iox issue: https://github.com/influxdata/influxdb_iox/issues/12407

@alamb note that this is a newly re-written commit, now that we advanced to the latest (on DF main) version of union_schema(). This is the remaining bit we patch to handle our iox-specific issue.

In order to get iox CI passing, I decided to back out the commit to turn on view types. See this PR description.
In brief, existing parquet with string fields was failing in our iox tests. IMO, we should try making this change separately. What do you think @alamb ?

I recommend:
1. Include the code change

2. Changing the influxdb_iox config to turn off the view types by default (e.g. https://github.com/influxdata/influxdb_iox/blob/496b298676097aaf0eb52f67957809f147ed4a56/datafusion_util/src/config.rs#L25-L29). Specifically set `datafusion.execution.parquet.schema_force_view_types` to `false`

3. File a ticket tracking the work needed to turn it on by default in IOx

Agreed that we should file this as a tech debt ticket in iox, to get us onto view types. However, I'm not sure whether our "tech debt state" should be the revert upstream commit -- or figuring out how to turn it off via the config.
Yesterday I tried turning off via the config first, but was still getting CI errors. Here is an example WIP showing that we need more than just setting the config. (Or maybe I'm missing another point of where the config should be set?)

Specifically, the CI errors were the bits mentioned in the PR description. It was still attempting to use utf8view types and failing the iox schema check. I could modify the check, but then it failed on the various iox-type to arrow-type mappings. Etc. It became clear that this was a larger thing, to be done in it's own (atomically revertable) pr IMO.

I just realized that this^^ observation may mean that we have an upstream DF bug. Since when turning off view types, we were still getting view types. 🤦🏼♀

And another thing that bugs me in upstream. There are a whole bunch of duplicate places where the ParquetTableOptions are provided in the session. Which is why I'm not sure if I'm (a) still missing a place to set the config (even after changing all of these places), or (b) there is a bug in upstream where DF is still internally trying to use view types when we turned it off. 🤷🏼♀

And another thing that bugs me in upstream. There are a whole bunch of duplicate places where the ParquetTableOptions are provided in the session.

What I normally do in this case is go start making small PRs upstream to make the situation better

Which is why I'm not sure if I'm (a) still missing a place to set the config (even after changing all of these places), or (b) there is a bug in upstream where DF is still internally trying to use view types when we turned it off. 🤷🏼♀

I likewise don't know -- can you give me a hint about how I can help you debug this (aka how do I reproduce the issue?)


addCancelAction - Still calls action

    var alertview = JSSAlertView().show(self, title: "title", buttonText: "Yes", cancelButtonText: "No")
    alertview.addAction(self.calltimeboosts)
    alertview.addCancelAction(self.uploadImgs)

Here is a simple alert view with a cancel button. When i click the action button it also calls the cancel button. at least in my opinion, it should be two separated actions. not linked.
Can we make a separated action for cancel

Oh wow, you're right. That's my fault. Will submit PR shortly

It's actually my fault for succumbing to self-imposed pressure and not testing things before merging. :disappointed: Thanks @sman591 and @v1n2e7t


auth

This pull request introduces a comprehensive set of changes to the authentication functionality of the application. The key changes include:

Initial Setup: The initial setup for the authentication v5 has been completed.
Lock File Fixes: The lock file has been updated to address any dependencies or version conflicts.
Authentication Configuration: The authentication configuration has been improved, addressing any issues or changes required.
Package Updates: New packages have been added to the project, enhancing the overall functionality.
Account Page and Logout: An account page has been implemented, allowing users to view their details and log out of the application.
Error Handling and User Feedback: Improved error handling and user feedback mechanisms have been added to provide a better user experience.
Login Layout and Page: A new login layout and page have been introduced, streamlining the authentication process.
Email Verification Flow: An email verification flow has been implemented to ensure secure user authentication.
Reusable Label Component: A new reusable label component has been added to the UI, improving consistency and maintainability.
Magic Link Authentication: The application now supports magic link authentication, providing an alternative login method.
Linting Fixes: Any linting issues within the authentication-related code have been addressed.

the auth and mail looks good,
i need it in my branch @joscha-st  plz accept


feat: add sourcekit-lsp

#329

I'm not sure it's that simple, at least I couldn't get this working myself. SourceKit is not available in Mason as it is installed separately

You can't install SourceKit via Mason as it comes bundled with the Swift toolchain itself. (more)

I'm not sure it's that simple, at least I couldn't get this working myself. SourceKit is not available in Mason yet

However, with this PR, you would be able to set up lspconfig if your lspconfig relies on mason-lspconfig.nvim. Here's how I’m doing it:


fix nsg rules logic

Proposal fix for NSG rules not being applied correctly.

Seems reasonable! This seems to have been introduced inadvertently with this commit and was probably a copy-paste overlook. I see that the allow_internet_outbound, allow_lb_inbound, allow_vnet_inbound and allow_vnet_outbound variables are completely unused due to this, and your PR returns them to a functional state.
@dutsmiller who does most of the maintenance on this module is on vacation since yesterday through next week, but I think everything looks good. Thanks! I'll merge this and release it shortly as v4.0.2.


Code workflow

efafvRVW

 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.:x: AkulaRushikesh sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

SGSGAGG


Add API to import application from template

This API should take the following information and create a template. The API should have access controlled so that it's not publicly accessible.
Required information to create a template:

Title
List of screenshots
Description
Link to public app
Created at
Updated at
Download count

FE : https://github.com/appsmithorg/appsmith/10747


How to manage the parameters units when using Mxnet for distributed deep learning?

I am a beginner in Mxnet. Parameters are transferred in the form of <key, value> pairs when using MXNET for distributed deep learning, according to the paper Parameter Server in 2014. (It implies parameters will be transferred in the unit of each layer.)
If I want to define the form by myself, for instance, I want the parameters in layer 1 and layer 2 or more layers packed and transferred together, what should I do?

Hi @ChrisQiqiang , it depends on what do you want to achieve when you pack them and transfer together.
I believe the parameters are still been updated one by one according to here: https://github.com/apache/incubator-mxnet/blob/master/python/mxnet/gluon/trainer.py#L361
However, KV store APIs allows you to update several keys together: https://mxnet.incubator.apache.org/api/python/docs/api/kvstore/index.html
You may want to ask questions on our discussion forums:
English: https://discuss.mxnet.io
Chinese: https://discuss.gluon.ai/


MT.1029 catching break glass accounts

The below check is catching break the glass accounts even if they've been accurately discovered. Is this by design or should it perhaps exclude break the glass accounts as they're almost always "stale"?
MT.1029: Stale accounts are not assigned to privileged roles.

MT.1029 does check for break glass and excludes them.
Can you run with -verbose and investigate?
  # Filtering based on (EntraOps) Enterprise Access Model Tiering
    if ($null -ne $FilteredAccessLevel) {
      Write-Verbose "Filtering based on Enterprise Access Model Tiering"
      $EamClassification = Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/Cloud-Architekt/AzurePrivilegedIAM/main/Classification/Classification_EntraIdDirectoryRoles.json' | ConvertFrom-Json -Depth 10
      $FilteredClassification = ($EamClassification | Where-Object { $_.Classification.EAMTierLevelName -eq $FilteredAccessLevel }).RoleId
      $AffectedRoleAssignments = $AffectedRoleAssignments | Where-Object { $_.RoleTemplateId -in $FilteredClassification }
    }

    # Exclude Break Glass from Alerts
    if ($null -ne $FilteredBreakGlass -and $null -ne $AffectedRoleAssignments) {
      $AffectedRoleAssignments | Where-Object { $_.AssigneeId -in $($FilteredBreakGlass).Id } | ForEach-Object {
        Write-Verbose "$($_.AssigneeUserPrincipalName) has been defined as Break Glass and removed from $($Alert.id)"
      }
      $AffectedRoleAssignments = $AffectedRoleAssignments | Where-Object { $_.AssigneeId -notin $($FilteredBreakGlass).Id }

      # Set number of affected Items to value of filtered items (for example, original alert has two affected items, but all of them are break glass and excluded from the test)
      $Alert.numberOfAffectedItems = $AffectedRoleAssignments.Count
    }


Use Artifactory to source the Kubernetes agent helm chart instead of Dockerhub

Background
We've been hitting rate limiting because docker is tightening up their rate limits.
Results
Instead of doing what we do in server which is to return inconclusive when dockerhub rate limits our request, we are just going to use Artifactory. This will eliminate the rate limiting but could cause failures if artifactory is done. Because this test doesn't have to run on the same scale as server, we don't need to stress too much about this. If it does fail, we can just rerun the test.

☝ No changeset required as this is just changes to tests

LGTM! Just checking, does 1.. resolve prerelease versions or just main versions?

As discussed in slack, we've tested this and 1.*.* does not resolve prerelease versions. 1.*.*-0 is what to use if you want to resolve the most recent pre-release version 👍


Marco Ghiani - Legacy Project

Calendar feature on dashboard, keep track of global snapshots by date.

Empty dot: some snapshots from entries.
Full dot: every entry has a snapshot on that specific date.

Progress feature on dashboard, calculate the average score of every snapshot and display a progress chart on  timeline. On another chart, every enabler is returned comparing the initial value and the current value from the oldest and the newest snapshot.

Snapshot creation is now based on date input.

Add dynamic title on views.

Schemas refactoring on the server

Fixed bugs on snapshot's creation

Fixed bug on refreshing pages

Fixed other bugs into components

Updated some style classes

Nice work Marco, I'll review this tomorrow!

Thank you!


Remove teh centos-9-stream-appstream from dockerfile

followup to https://github.com/kubev2v/forklift-must-gather/pull/90

/retest


Fix: Changes PolylineOptions 'icon?:Array' to 'icons?:Array'

Fixes #948
Changes the typename from 'icon?:Array' to 'icons?:Array' according to Google API.
Source: https://developers.google.com/maps/documentation/javascript/examples/overlay-symbol-dashed

thanks!


Remove loading profile messages

Done in https://github.com/macterra/artx-market/commit/d072719258218aa92bb4bb5837417eee150c0a6a


[WIP] ci: Remove setup_cache.sh

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@wbpcode as discussed on previous pr this removes setup_cache.sh altogether
my hesitance to remove it previously was due to the fact that its currently hooked up to both the dev container and in mac/windows ci - so i need to check in each case that nothing is broken etc


feat(common): Introduced common library for all sub-services

Issues
Fixes #
Reviewer Suggestions
Where should the reviewer start?
Additional Comments
Anything else?

:tada: This PR is included in version 0.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Adding Toolbelt

Regarding Issue #35

These graphical changes you are making look really cool. I like it.


New version: Microsoft.OneDrive.Internal.Slow version 23.176.0822.0001

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

2023-08-25 18:45:20.705 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(52)\WindowsPackageManager.dll!00007FF8F2A612BA: (caller: 00007FF8F2A62129) Exception(2) tid(22ec) 80072EFD     Msg:[InternetOpenUrl() failed.]
2023-08-25 18:45:20.799 [CLI ] Failed to download, waiting a bit and retry. Url: https://oneclient.sfx.ms/Win/Installers/23.176.0822.0001/amd64/OneDriveSetup.exe

/AzurePipelines run

Reset PR


Add 'from: undefined' to PostCSS options

Description of change

Pull-Request Checklist

[ ] Code is up-to-date with the main branch
[ ] npm run lint passes with this change
[ ] npm run test passes with this change
[ ] This pull request links relevant issues as Fixes #0000
[ ] There are new or updated unit tests validating the change
[ ] Documentation has been updated to reflect this change
[ ] The new commits follow conventions outlined in the conventional commit spec

Sorry, I meant to push this to my fork. I may make a change back once I look further into this, but not sure if it will make sense to change anything here.


[i2c/dv] Add option to control i2c agent verbosity

instead of relying on UVM_HIGH which tends to bring in too much information while debugging, @martin-lueker suggested we follow aes and entropy_src example and do it with more granularity.
See this example for how it can be done.

@jdonjdon up to you whether this is needed for V2 or not.

@jdonjdon up to you whether this is needed for V2 or not.

ack. I will update nextweek.

@jdonjdon i think this one really belongs in the backlog category, it serves no real DV purpose otherwise.
Let me know if you disagree, otherwise I'll drop it to P4 for now.

I agree with putting this to p4.

Low prio DV ergonomics improvement --> M5 (may slip to backlog)

Discussed during triage meeting and decided to close as not planned.


evaluation script

For further information see skript.sh + errorlog.txt

Last pull request

Last pull request


how to ignore ssl check?

While using self-signed cert, got below error.
I think disable the ssl check on may fixed it, but I don't know how to do it.
May you please provide a sample for it? thanks.
Here is the code:
use K8s\Api\Model\Api\Core\v1\Pod;
use K8s\Client\K8sFactory;

$k8s = (new K8sFactory())->loadFromKubeConfig();

/** @var Pod $pod */
foreach ($k8s->listAll(Pod::class) as $pod) {
  echo sprintf(
      "%s\t%s\t%s",
      $pod->getPodIP(),
      $pod->getNamespace(),
      $pod->getName()
    ) . PHP_EOL;
}

PHP Fatal error:  Uncaught Symfony\Component\HttpClient\Exception\TransportException: SSL peer certificate or SSH remote key was not OK for "https://<IP_ADDRESS>:6443/api/v1/pods". in /Users/terry/www/php-k8s-client/vendor/symfony/http-client/Response/CurlResponse.php:317
Stack trace:
#0 /Users/terry/www/php-k8s-client/vendor/symfony/http-client/Response/TransportResponseTrait.php(170): Symfony\Component\HttpClient\Response\CurlResponse::perform(Object(Symfony\Component\HttpClient\Internal\CurlClientState), Array)
#1 /Users/terry/www/php-k8s-client/vendor/symfony/http-client/Response/CommonResponseTrait.php(156): Symfony\Component\HttpClient\Response\CurlResponse::stream(Array)
#2 /Users/terry/www/php-k8s-client/vendor/symfony/http-client/Response/TransportResponseTrait.php(53): Symfony\Component\HttpClient\Response\CurlResponse::initialize(Object(Symfony\Component\HttpClient\Response\CurlResponse))
#3 /Users/terry/www/php-k8s-client/vendor/symfony/http-client/Psr18Client.php(99): Symfony\Component\HttpClient\Response\CurlRes in /Users/terry/www/php-k8s-client/vendor/symfony/http-client/Psr18Client.php on line 120

I think you would need to do something like this:
use K8s\HttpSymfony\ClientFactory;
use K8s\Client\K8sFactory;

$httpFactory = new ClientFactory([
    'verify_peer' => false,
    'verify_host' => false,
]);

$k8s = (new K8sFactory())->loadFromKubeConfig(null, $httpFactory);

I added this to the docs for the Symfony HTTP client part here:
https://github.com/k8s-client/http-symfony#default-http-options-configuration
Let me know if this helps!

@ChadSikorra Thanks.
got below error.

$k8s is init sucessfully
kubectl get po -A can execute sucessfully

PHP Fatal error:  Uncaught K8s\Client\Exception\KubernetesException: pods is forbidden: User "system:anonymous" cannot list resource "pods" in API group "" at the cluster scope in /Users/terry/www/php-k8s-client/vendor/k8s/client/src/K8s/Client/Http/ResponseHandler/ErrorHandler.php:36
Stack trace:
#0 /Users/terry/www/php-k8s-client/vendor/k8s/client/src/K8s/Client/Http/HttpClient.php(109): K8s\Client\Http\ResponseHandler\ErrorHandler->handle(Object(Nyholm\Psr7\Response), Array)
#1 /Users/terry/www/php-k8s-client/vendor/k8s/client/src/K8s/Client/Kind/KindManager.php(397): K8s\Client\Http\HttpClient->send('https://192.168...', 'list', Array)
#2 /Users/terry/www/php-k8s-client/vendor/k8s/client/src/K8s/Client/Kind/KindManager.php(273): K8s\Client\Kind\KindManager->execute('list-all', Array, 'K8s\\Api\\Model\\A...')
#3 /Users/terry/www/php-k8s-client/vendor/k8s/client/src/K8s/Client/K8s.php(199): K8s\Client\Kind\KindManager->listAll('K8s\\Api\\Model\\A...', Array)
#4 /Users/terry/www/php-k8s-client/demo.php(46): K8s\Client\K8s->li in /Users/terry/www/php-k8s-client/vendor/k8s/client/src/K8s/Client/Http/ResponseHandler/ErrorHandler.php on line 36

What does your kubeconfig file look like? (just remove anything sensitive..). My guess is maybe it uses exec or something else this library doesn't support yet.

I send it to<EMAIL_ADDRESS>find it from https://www.chadsikorra.com/about)

Thanks, got it. After looking at it, it appears that for authentication it uses client certificates as base64 strings. The issue is that there is no way in PHP (for cURL anyway) to specify a certificate from anything other than a file path. So a workaround would have to include writing the certificate data locally on the filesystem somewhere, then referencing it for the options in Symfony.
I'll have to think a bit on how I want to do this.
An alternative workaround for the moment could be to reference a file path to the certificate using client-certificate and client-key in your kubeconfig.

@ChadSikorra
After using the certs file, it works. Thanks for help!

PHP 8.1+ and newer libcurl versions added support for using string cert data instead of file paths. I added support for this in the the Symfony HTTP Client adapter (Guzzle does not support adding these options unfortunately). Tagged a new release for it:
https://github.com/k8s-client/http-symfony/releases/tag/1.1.0


chore: add keycloak for acc tests

This adds documentation for running a keycloak server that can be used to test SAML/OAuth and Browser based workflows. More work will need to be done to automate the process. Perhaps with https://github.com/compose-spec/compose-go to start up container automatically.

This adds documentation for running a keycloak server that can be used to test SAML/OAuth and Browser based workflows. More work will need to be done to automate the process. Perhaps with https://github.com/compose-spec/compose-go to start up container automatically.

I like it. I think we can merge it without adding any automation for it now. We can add it as a part of SNOW-999050.
I did not try to run it myself yet, but the description looks solid. I left just one question for the realm json.


feat: add service requests home

This adds a link to service requests home in the main menu for logged-in users.
Clicking the link takes you to the service requests index page

The reason I created two components for CurrentServiceRequests and ClosedServiceRequests is that the logic that would be needed to load the actual requests, and how we display them might be significantly different enough.
If it turns out that it is not, we can look at refactoring this down to one component that returns the appropriate data/view based on a prop for example.


Using Structured Outputs throws body used already for: https://api.openai.com/v1/chat/completions in 4.59.0

Confirm this is a Node library issue and not an underlying OpenAI API issue

[X] This is an issue with the Node library

Describe the bug
Since 4.59.0, using structured outputs with Zod causes the following error:
TypeError: body used already for: https://api.openai.com/v1/chat/completions
    at Response.consumeBody (/dev/app/node_modules/node-fetch/lib/index.js:344:30)
    at Response.json (/dev/app/node_modules/node-fetch/lib/index.js:269:22)
    at Proxy.defaultParseResponse (/dev/app/node_modules/openai/src/core.ts:68:33)
    at /dev/app/node_modules/openai/src/core.ts:121:42
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at /dev/app/dist/apps/api/main.js:4027:32

To Reproduce
You can reproduce by using the chat completions endpoint with structured outputs. I haven't tried this without Zod.
const completion = await this.client.beta.chat.completions.parse(
  {
    model: "gpt-4o-mini-2024-07-18",
    temperature: 0,
    messages: [
      {
        role: "system",
        content: prompt,
      },
      {
        role: "user",
        content: input,
      },
    ],
    response_format: zodResponseFormat(schema, schemaName),
  },
  { timeout: 60_000 },
);

Using this.client.chat.completions.create with response_format: { type: "json_object" } works just fine.
This is a regression introduced in v4.59.0
Code snippets
No response
OS
macOS
Node version
v20.13.1
Library version
4.59.0

Looking at a comparison with v4.58.2 and v4.59.0: https://github.com/openai/openai-node/compare/v4.58.2...v4.59.0
This seems like the most likely candidate: https://github.com/openai/openai-node/pull/1058

Thanks for the report @jreidgreer, I can't reproduce this, could you share more details about how you're using the SDK?

@jreidgreer can you share a stackblitz or equivalent that reproduces the bug?


Log remaining names in operator test

[Please provide a description of this PR:
](https://github.com/istio/istio/issues/37661)

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-istiodremote-mc_istio
45c422f603e234f4546f80c36dc0e0ee0fad2aba
link
true
/test integ-pilot-istiodremote-mc_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


updated meta description

@Khairunj,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\g421-s, target branch: live, target branch commit: f053f361c8e61f07fbad31cdef39d1e4a91f76bb, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\zund-s, target branch: live, target branch commit: f053f361c8e61f07fbad31cdef39d1e4a91f76bb, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\4zb0-s, target branch: live, target branch commit: f053f361c8e61f07fbad31cdef39d1e4a91f76bb, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\sz0c-s, target branch: live, target branch commit: f053f361c8e61f07fbad31cdef39d1e4a91f76bb, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\rkzw-s, target branch: live, target branch commit: f053f361c8e61f07fbad31cdef39d1e4a91f76bb, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\rxm2-s, target branch: live, target branch commit: 6b28d9419787db09f7b2a28c07cfdc587f589f74, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/globalization, working directory: W:\shsz-s, target branch: live, target branch commit: 53c97f5e11a5a59fe6aeb6c2c71f028aa6f608cf, source branch: master, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

closing to see if this cleans tihngs up


🐛 Unusable raw error message in iOS UI upon invalid credentials

Is there an existing issue for this?

[X] I have searched the existing issues and found no duplicates.

What plugin is this bug for?
Firebase UI Auth
What platform(s) does this bug affect?
iOS
List of dependencies used.

flutter pub deps -s list
Dart SDK 3.1.4
Flutter SDK 3.13.8
complete 0.1.0

dependencies:
- firebase_auth 4.13.0
  - firebase_auth_platform_interface ^7.0.4
  - firebase_auth_web ^5.8.7
  - firebase_core ^2.22.0
  - firebase_core_platform_interface ^5.0.0
  - flutter any
  - meta ^1.8.0
- firebase_core 2.22.0
  - firebase_core_platform_interface ^5.0.0
  - firebase_core_web ^2.8.1
  - flutter any
  - meta ^1.8.0
- firebase_ui_auth 1.10.0
  - email_validator ^2.1.17
  - firebase_auth ^4.11.1
  - firebase_core ^2.19.0
  - firebase_dynamic_links ^5.4.1
  - firebase_ui_localizations ^1.8.0
  - firebase_ui_oauth ^1.4.14
  - firebase_ui_shared ^1.4.1
  - flutter any
  - flutter_localizations any
- firebase_ui_oauth_google 1.2.14
  - firebase_auth ^4.11.1
  - firebase_ui_oauth ^1.4.14
  - flutter any
  - google_sign_in ^6.1.0
- flutter 0.0.0
  - characters 1.3.0
  - collection 1.17.2
  - material_color_utilities 0.5.0
  - meta 1.9.1
  - vector_math 2.1.4
  - web 0.1.4-beta
  - sky_engine any
- google_sign_in 6.1.6
  - flutter any
  - google_sign_in_android ^6.1.0
  - google_sign_in_ios ^5.5.0
  - google_sign_in_platform_interface ^2.4.0
  - google_sign_in_web ^0.12.0

dev dependencies:
- flutter_test 0.0.0
  - flutter any
  - test_api 0.6.0
  - matcher 0.12.16
  - path 1.8.3
  - fake_async 1.3.1
  - clock 1.1.1
  - stack_trace 1.11.0
  - vector_math 2.1.4
  - async 2.11.0
  - boolean_selector 2.1.1
  - characters 1.3.0
  - collection 1.17.2
  - material_color_utilities 0.5.0
  - meta 1.9.1
  - source_span 1.10.0
  - stream_channel 2.1.1
  - string_scanner 1.2.0
  - term_glyph 1.2.1
  - web 0.1.4-beta
- flutter_lints 3.0.1
  - lints ^3.0.0

transitive dependencies:
- _fe_analyzer_shared 61.0.0
  - meta ^1.0.2
- _flutterfire_internals 1.3.12
  - collection ^1.0.0
  - firebase_core ^2.22.0
  - firebase_core_platform_interface ^5.0.0
  - flutter any
  - meta ^1.8.0
- analyzer 5.13.0
  - _fe_analyzer_shared ^61.0.0
  - collection ^1.17.0
  - convert ^3.0.0
  - crypto ^3.0.0
  - glob ^2.0.0
  - meta ^1.7.0
  - package_config ^2.0.0
  - path ^1.8.0
  - pub_semver ^2.0.0
  - source_span ^1.8.0
  - watcher ^1.0.0
  - yaml ^3.0.0
- args 2.4.2
- async 2.11.0
  - collection ^1.15.0
  - meta ^1.1.7
- boolean_selector 2.1.1
  - source_span ^1.8.0
  - string_scanner ^1.1.0
- characters 1.3.0
- clock 1.1.1
- collection 1.17.2
- convert 3.1.1
  - typed_data ^1.3.0
- crypto 3.0.3
  - typed_data ^1.3.0
- desktop_webview_auth 0.0.14
  - crypto ^3.0.3
  - flutter any
  - http ^1.0.0
  - flutter_web_plugins any
  - plugin_platform_interface ^2.1.4
- email_validator 2.1.17
- fake_async 1.3.1
  - clock ^1.1.0
  - collection ^1.15.0
- file 7.0.0
  - meta ^1.9.1
  - path ^1.8.3
- firebase_auth_platform_interface 7.0.4
  - _flutterfire_internals ^1.3.12
  - collection ^1.16.0
  - firebase_core ^2.22.0
  - flutter any
  - meta ^1.8.0
  - plugin_platform_interface ^2.1.3
- firebase_auth_web 5.8.7
  - firebase_auth_platform_interface ^7.0.4
  - firebase_core ^2.22.0
  - firebase_core_web ^2.8.1
  - flutter any
  - flutter_web_plugins any
  - http_parser ^4.0.0
  - js ^0.6.3
  - meta ^1.8.0
- firebase_core_platform_interface 5.0.0
  - collection ^1.0.0
  - flutter any
  - flutter_test any
  - meta ^1.8.0
  - plugin_platform_interface ^2.1.3
- firebase_core_web 2.8.1
  - firebase_core_platform_interface ^5.0.0
  - flutter any
  - flutter_web_plugins any
  - js ^0.6.3
  - meta ^1.8.0
- firebase_dynamic_links 5.4.4
  - firebase_core ^2.22.0
  - firebase_core_platform_interface ^5.0.0
  - firebase_dynamic_links_platform_interface ^0.2.6+12
  - flutter any
  - meta ^1.8.0
  - plugin_platform_interface ^2.1.3
- firebase_dynamic_links_platform_interface 0.2.6+12
  - _flutterfire_internals ^1.3.12
  - firebase_core ^2.22.0
  - flutter any
  - meta ^1.8.0
  - plugin_platform_interface ^2.1.3
- firebase_ui_localizations 1.8.0
  - flutter any
  - flutter_localizations any
  - path ^1.8.2
- firebase_ui_oauth 1.4.14
  - desktop_webview_auth ^0.0.13
  - firebase_auth ^4.11.1
  - firebase_ui_auth ^1.10.0
  - firebase_ui_shared ^1.4.1
  - flutter_svg ^2.0.7
  - flutter any
- firebase_ui_shared 1.4.1
  - flutter any
- flutter_localizations 0.0.0
  - flutter any
  - intl 0.18.1
  - characters 1.3.0
  - clock 1.1.1
  - collection 1.17.2
  - material_color_utilities 0.5.0
  - meta 1.9.1
  - path 1.8.3
  - vector_math 2.1.4
  - web 0.1.4-beta
- flutter_svg 2.0.9
  - flutter any
  - vector_graphics ^1.1.9+1
  - vector_graphics_codec ^1.1.9+1
  - vector_graphics_compiler ^1.1.9+1
- flutter_web_plugins 0.0.0
  - flutter any
  - characters 1.3.0
  - collection 1.17.2
  - material_color_utilities 0.5.0
  - meta 1.9.1
  - vector_math 2.1.4
  - web 0.1.4-beta
- glob 2.1.2
  - async ^2.5.0
  - collection ^1.15.0
  - file >=6.1.3 <8.0.0
  - path ^1.8.0
  - string_scanner ^1.1.0
- google_identity_services_web 0.2.2
  - js ^0.6.4
  - meta ^1.3.0
- google_sign_in_android 6.1.20
  - flutter any
  - google_sign_in_platform_interface ^2.2.0
- google_sign_in_ios 5.6.5
  - flutter any
  - google_sign_in_platform_interface ^2.2.0
  - pigeon ^11.0.1
- google_sign_in_platform_interface 2.4.2
  - flutter any
  - plugin_platform_interface ^2.1.0
  - quiver ^3.0.0
- google_sign_in_web 0.12.1
  - flutter any
  - flutter_web_plugins any
  - google_identity_services_web ^0.2.2
  - google_sign_in_platform_interface ^2.4.0
  - http >=0.13.0 <2.0.0
  - js ^0.6.3
- http 1.1.0
  - async ^2.5.0
  - http_parser ^4.0.0
  - meta ^1.3.0
- http_parser 4.0.2
  - collection ^1.15.0
  - source_span ^1.8.0
  - string_scanner ^1.1.0
  - typed_data ^1.3.0
- intl 0.18.1
  - clock ^1.1.0
  - meta ^1.0.2
  - path ^1.8.0
- js 0.6.7
  - meta ^1.7.0
- lints 3.0.0
- matcher 0.12.16
  - async ^2.10.0
  - meta ^1.8.0
  - stack_trace ^1.10.0
  - term_glyph ^1.2.0
  - test_api >=0.5.0 <0.7.0
- material_color_utilities 0.5.0
  - collection ^1.15.0
- meta 1.9.1
- package_config 2.1.0
  - path ^1.8.0
- path 1.8.3
- path_parsing 1.0.1
  - vector_math ^2.1.0
  - meta ^1.3.0
- petitparser 5.4.0
  - meta ^1.9.0
- pigeon 11.0.1
  - analyzer ^5.13.0
  - args ^2.1.0
  - collection ^1.15.0
  - meta ^1.7.0
  - path ^1.8.0
  - yaml ^3.1.1
- plugin_platform_interface 2.1.6
  - meta ^1.3.0
- pub_semver 2.1.4
  - collection ^1.15.0
  - meta ^1.3.0
- quiver 3.2.1
  - matcher ^0.12.10
- sky_engine 0.0.99
- source_span 1.10.0
  - collection ^1.15.0
  - path ^1.8.0
  - term_glyph ^1.2.0
- stack_trace 1.11.0
  - path ^1.8.0
- stream_channel 2.1.1
  - async ^2.5.0
- string_scanner 1.2.0
  - source_span ^1.8.0
- term_glyph 1.2.1
- test_api 0.6.0
  - async ^2.5.0
  - boolean_selector ^2.1.0
  - collection ^1.15.0
  - meta ^1.3.0
  - source_span ^1.8.0
  - stack_trace ^1.10.0
  - stream_channel ^2.1.0
  - string_scanner ^1.1.0
  - term_glyph ^1.2.0
- typed_data 1.3.2
  - collection ^1.15.0
- vector_graphics 1.1.9+1
  - flutter any
  - vector_graphics_codec 1.1.9+1
- vector_graphics_codec 1.1.9+1
- vector_graphics_compiler 1.1.9+1
  - args ^2.3.0
  - meta ^1.7.0
  - path_parsing ^1.0.1
  - xml ^6.3.0
  - vector_graphics_codec 1.1.9+1
  - path ^1.8.0
- vector_math 2.1.4
- watcher 1.1.0
  - async ^2.5.0
  - path ^1.8.0
- web 0.1.4-beta
- xml 6.3.0
  - collection ^1.17.0
  - meta ^1.9.0
  - petitparser ^5.4.0
- yaml 3.1.2
  - collection ^1.15.0
  - source_span ^1.8.0
  - string_scanner ^1.1.0

Steps to reproduce
To reproduce just follow the steps in the FirebaseUI Auth codelab, specifically:

Codelab Step 2: Follow the instructions, make sure to create a new Firebase project. I used the free 'Spark` plan with default settings.

NB This issue seems to be somehow related to the config of the Firebase project, so this is likely a critical step. See detaisl below.

Codelab Step 3: Get the starter code, or the 'complete' code from the Codelab GitHub Repository).  I initially followed the entire lab but the Codelab implementation details don't affect this issue, so the easiest way is the shortcut and download the 'complete` project from GitHub

Note: I have had the same issue in all my firebase_ui_auth projects (also see Issue #25), but the codelab project is the easiest way to reproduce and is what I used to investigate this issue (details below)

Make sure to use flutterfire configure, per the codelab, to generate the firebase_options.dart

In my case flutterfire configure generated an error as follows:
i Found 4 Firebase projects. Selecting project flutterfire-ui-codelab. FirebaseProjectNotFoundException: Firebase project id "flutterfire-ui-codelab" could not be found on this Firebase account.

Note that flutterfire-ui-codelab is another (my initial) Firebase project (it's actually flutterfire-ui-codelab-e0f34, so there is possibily a seperate bug here with flutterfire config), and not the new, clean Firebase project I wanted to use for this test.  To circumvent I explictly specified the Firebase project to be configured using: flutterfire configure -p flutterfire-ui-codelab2-260ce.  This successfully generated my firebase_options.dart file.

Skip Codelab Steps 4-8: These are not needed if you've downloaded the 'complete' code from the Codelab GitHub Repository). Use the following steps instead
Step 4: In theory the codelab 'complete' code should now run... However in my case it generated the following error (which flutter clean && flutter pub get does not resolve):
Unhandled Exception: [core/duplicate-app] A Firebase App named "[DEFAULT]" already exists

This can be resolved in 2 ways (I've done both, with no impact to the issue here)
Step 4: Option a:  The codelab 'complete' project has a GoogleService-Info.plist in the ios/Runner folder. Replacing this with the GoogleService-Info.plist from my own Firebase project is the simplest way to resolve the issue and will result in a working ios app displaying this issue
Step 4: Option b:  Delete the ios folder and its content and recreate the ios content with flutter create . --platforms ios. This results in the same outcome as Step 4a

You should now have a working app which displays the issue documented here when run on an iOS simulator (I used both iPhone 14 and iPhone 14 Pro with the default (latest, I assume) iOS.
NOTE: There are 2 issues I identified with the codelab 'complete' code but which do not affect this issue here.  For completeness these are:

Issue 1: The images in home.dart don't display in the app because the image path is missing assets/ before the image filename
Issue 2 (only arrises if Step 4b (ios re-create) is done): The widget_test.dart file (which is created when the ios app is re-created), does not recognise the MyApp() because the 'complete' code has a separate app.dart file for this class rather than it being part of the usual import 'package:complete/main.dart';
These issues are easily rectified, but as noted, don't effect the issue here.

Expected Behavior
The ios app should render reasonable user error messages in the app UI (via the SignInScreen widget) when the user enters invalid email and password credentials (either invalid / non-existent account, or wrong password).
Examples as follows:

NOTE: Having separate error messages for invalid / non-existent account and wrong password is, in my view, not a good security practice as it allows people to discover valid accounts and greatly simplifies hacking of passwords.
NOTE2:  The error messages for web clients and android clients are different from the ios (expected behavior) messages above. The web client simply shows the text Error in red, while adnroid show different red text:
'An internal error has occurred. [ INVALID_LOGIN_CREDENTIALS ]'
In my view it would be a much better UX to show consistent error messages across all platforms. Also see Issue #25 where this is also discussed.
Actual Behavior
When the user enters invalid email and password credentials (either invalid / non-existent account, or wrong password) the following raw error message is rendered to the UI via the SignInScreen widget:

Full message when scrolling down:

I view this as an unacceptable and unusable User Experience, and it would prevent me from using the firebase_ui_auth package.
Additional Information
I believe this issue may be related to how the Firebase project is setup.  Hence the emphasis in reproduction Step 2 above.
The reason for this is that there is another - not very good way, but an instructive way - to resolve the Unhandled Exception: [core/duplicate-app] A Firebase App named "[DEFAULT]" already exists issue I encountered at Step 4 above.  I'll call this Step 4 - Option c and will describe the behavior and my associated hypothesis

Step 4 - Option c:  Instead of replacing the GoogleService-Info.plist file, or recreating the ios build, it is possible to get the app working - with the expected error messages ! by adding a name: parameter to the Firebase.initializeApp in main(). I discovered this while trying to debug the issue and from this StackOverflow article.  Example as follows:

  await Firebase.initializeApp(
    name: 'test-app',
    options: DefaultFirebaseOptions.currentPlatform,
  );

This results in a working app with the expected UI error messages (and was used to generate the screenshots in the Expected Behavior section
However this results in weird behavior where users that we previously registered in my Firebase project are no longer available, but new users can be registered and logged in.  Furthermore these same new users can be accessed regardless of the name: value used and don't appear anywhere in my Firebase project.

HYPOTHESIS:
Part 1: Using the combo of GoogleService-Info.plist and project.pbxproj from the original codelab complete folder seems to redirect my app to the codelab Firebase instance (PROJECT_ID flutterfire-ui-codelab referenced in GoogleService-Info.plist), which is why I can't see the users I've added there (like<EMAIL_ADDRESS>and<EMAIL_ADDRESS>in my own Firebase project.
Part 2: Somehow the codelab Firebase instance (PROJECT_ID flutterfire-ui-codelab) is configured differently than mine and this causes the invalid credentials UI error messages to work correctly, while my basic, free and default Firebase config causes the bad UI error messages.
I hope all this helps track down this issue and helps to get it fixed.

Hi @Arik-AOS-dev, I suspect this is due to email enumeration protection being enabled on your project. Can you try disabling it to see if you do get the correct error messages? You can disable it by following https://cloud.google.com/identity-platform/docs/admin/email-enumeration-protection#disable

Hi @danagbemava-nc, many thanks for the response.  I can confirm that indeed email enumeration protection is the source of this issue!
When I disable the email enumeration protection (per the instructions), the SignInScreen returns the expected error messages in the UI.  FYI the setting which this came back for this in GCP console was simply:
  "emailPrivacyConfig": {}

When I subsequently re-enabled the email enumeration protection in GCP console (and without any changes, or even reloads in my app) the UI error re-appeared.  FYI the relevant returned setting in this case was:
  "emailPrivacyConfig": {
    "enableImprovedEmailPrivacy": true
  }

While disabling email enumeration protection removes the issue, I hope we can agree it should not be a long-term workaround given a) it's now enabled by default (since Sept 15th, 2023) and b) Google recommends having it enabled.
Coincidentally, I also mentioned this email enumeration issue in my NOTE: above in relation to the existing, expected error messages:

NOTE: Having separate error messages for invalid / non-existent account and wrong password is, in my view, not a good security practice as it allows people to discover valid accounts and greatly simplifies hacking of passwords.

It would be great if the resolution to this issue could also fix this and align the error messages for consistency across the platform.  Thanks for the support !

Hi @Arik-AOS-dev, thanks for confirming.
So the error message is not from the firebase_ui_auth but from the underlying firebase_auth plugin.
Transferring this to the flutterfire repo.


Runtime workers local pools.

This PR extracts part of #7687 related to worker management.
Mainly :

per execution worker pool
new runtime tasks host functions 'set_capacity' and 'dismiss'
inline executor (no threads and no_std).

Per executor management
When launching a execution, from runtime the number of worker can be manage.
The new host function 'set_capacity' indicates the runtime worker needs.
This is only an indicative information, and in practice can be limited by client
configuration.
I did not put configuration that would multiply this for environment with very high
parallelism, but it can be an idea.
The idea that the runtime define its own number of worker should allow to define
some static pool of worker initialization cost if needed.
Note that at this point the pool never diminished so a 'set_capacity' is
internally always true for the whole execution (execution are not very long.
inline worker
This PR allows runing worker code inline, without parallelism.
In this case the worker run on 'join' operation only (so a 'dismiss' worker doesn't run at all).
The inline worker code is 'no_std' compatible, to be able to run the worker io function under
pure wasm host function with cumulus: see test TODO link
This is rather questionable as if the chain need worker, it is probable that we would like
them also when running the validation function.
And it also involve some additional code:

'HostLocalFunction' trait.
hosted_runtime code.
That are only safe in environment where there is no threads.

worker termination
Trait 'DismissHandle' allow dismissing a worker. It is currently only implemented
for the test executor (we can use the future pool handle there). For standard
execution it is not use.
Therefore for management of those handles in the default substrate executor,
is gatted behind 'abort-future' feature, since in practice it is just an overhead.
Worker panic
Under current design, a worker panic will always panic the parent worker.
First design makes it optional. But to allow cumulus running without worker by
running a wasm compatible inline executor, we cannot always catch panic.
This does not sounds too bad to me as panic only ever happen on 'join', so never
for a dismissed worker.
global worker limit
A global worker limit is configurable, see trait 'SpawnLimiter', this just a limit
to the total number of worker that can be allocated for a client.
It only got two operations, try_acquire and release, that update a global number of
available worker.
So if an execution run at some point where this is depleted, all its workers
will run 'inline' except if it does a call to 'set_capacity' during execution.
Note that better implementation could load balance among execution (and update
limit when an execution release), but here we got
a very basic implementation.
Review note

many content in executor/common/src/inline come from previously executor native spawn (move to factorize inline executor and standard one).
Some api from #7687 are kept with FIXME in comment.

Consideration at this point

the code uses a lot of unsafe externalities mutable access, the code is a bit awkward there (see with_externalities_and_extension),
and assume call to extension do not modify the extension container.
having running worker thread only for the length of an execution is probably too short, the limiter global trait could be
extend with the pool message from the 'native executor' and keep channel to the open threads with reference to the runtimes
(and possibly updates), but it does not look like a simple api.

Putting 'in progress' as the depnedency rules violation may require to move a lot of things around.

Putting 'in progress' as the depnedency rules violation may require to move a lot of things around.

Got the organisation reworked, some of sc-executor-common was moved to sp-tasks in the process.

Got the organisation reworked, some of sc-executor-common was moved to sp-tasks in the process.

Out of curiosity, what's the roadmap of worker threads? Is there any plan to make them communicate with one another (no shared state, something like mpsc)?

No idea about roadmap.
Th way I see it 'mpsc' is shared state (ok not trie state iiuc). Deterministic mpsc does not sound simple to me (maybe with static definition of channels and some constraint that would make it hard to use (like blocking only recv)), but I must admit I did not give it much thought.
CC @NikVolf

https://github.com/paritytech/substrate/pull/7978/commits/ee128b598dba74840151e31efd006185c1ca350c does remove unused types, limiting this PR scope for easier review.

Setting audit label as 'D1-trivial' since this is an experimental api and just a subpart of a bigger PR, and it is probably too soon to audit.


last() not working as expected

When using last() as a filter, I would expect that the returned node would be the last one as ordered by location in the XML document (i.e. the ordering coming out of applyLocationPath). The way that predicates are applied, however, is on an unsorted array which can (and in my case did) lead to the a different node (i.e. an earlier one) being returned.

This issue was happening on 0.0.32 of the library. Let me know if further details here would be helpful.

This is a shortened version of the file I was working with that still reproduces the issue that I am talking about:

            This is a test!

                            This is also a test!

Running the path expression (.//*[local-name(.)='blockquote'])[not(@class="gmail_quote") and not(ancestor::blockquote)][last()] will return the This is a test block rather than the expected top level of the This is also a test block.

Thank you for reporting this. This wasn't actually an issue with the last() function but rather an issue with the handling of context positions. Should now be fixed in version 0.0.34.


memory usage growth after a while

I have tested the code on GTX 1080 with 32g Ram but when I run the code memory usage increases over time and after about 30 hours it will take all 32g of ram and make system to dies

Hi, can you provide some more details? Are you using the basic version of the algorithm with Pong? Automatic scheduling enabled? How many agents / trainers / predictors? Is the number of agents / training / predictor growing during training or does it stabilize? Thanks

Hi, yes I do use the basic version with Breakout game and Dynamic setting is off and 32 agents running with 2 trainer threads and 2 predictor threads. all the settings are fixed during training but memory usage will growth. I think this may be because of tensorflow memory leak.

Tensor flow version?

tensorflow version 1.2.1
installing from binary
cuda version 7.5


How to send data to the end nodes?

If it is possible, please include an example on how to send data (payload) to the end nodes. If I am not mistaken, currently there is no example for sending data only for receiving it. Thanks!

Do you mean this? https://docs.loraserver.io/loraserver/sending-data/

Unfortunately I have no experience with mosquitto. I understand what is needed to send packets to an end node, but what I miss is a sample mosquitto command like mosquitto_sub -t "application/0101010101010101/node/+/rx" -v you wrote for receiving packets.


Don't use title for dialog/wizard events

Currently if a telemetry name isn't specified we default to the title of the dialog/wizard/page. Instead we should just default to a generic name if a telemetry name isn't specified.

Turns out we're already doing this, there was just a bug in an extension causing this to look like it was using the title.


[DOWNSTREAM-ONLY] deploy: use OpenShift recommended parameters for leader election

See-also: csi-addons/kubernetes-csi-addons#505
Signed-off-by: Niels de Vos<EMAIL_ADDRESS>

/hold
This needs to wait for the next downstream-sync PR that includes csi-addons/kubernetes-csi-addons#505

/unhold
#111 has been merged


feat: add publishing lock

fixes #341
screens:

Yeah, I've been thinking about how best to incorporate an approval flow into the UI in a way that's intuitive. My thinking right now is that if an approval config is enabled, we would force all publishing to go through the "Release" process and the "Publish" button on the document page would be changed to "Add to release" (or "Go to release"). The release can contain 1 or more doc, a description of the release, and snapshots of before/after for each doc in the release. This would be similar to a GitHub PR - we can maybe even enable comments by allowing people to comment within the snapshot.
Within this release review system, we can enable "presubmit checks" like you're suggesting (e.g. checking for blocked terms).


S3: UploadPartCopy returns empty ETag

version 1.0.5
UploadPartCopyOutcome.IsSuccess() // is true, but
UploadPartCopyOutcome.GetResult().GetCopyPartResult().GetETag().c_str() //is empty
response trace is like below:
_[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] HTTP/1.1 200 OK^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] x-amz-id-2: 17xx0lYEeN8JrXesoR0pwsVbrjTfSLKJFS3R/w2mh5D6rEuKcgcdrY6gI6b3FhDi7iMKP5gE4iE=^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] x-amz-request-id: 94835C69A185CD58^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Date: Mon, 19 Sep 2016 04:40:48 GMT^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Content-Type: application/xml^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Content-Length: 230^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Server: AmazonS3^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] ^M
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] 230 bytes written to response.
[DEBUG] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Returned http response code 200
[DEBUG] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Returned content type application/xml
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Response content-length header: 230
[TRACE] 2016-09-19 00:40:54 CurlHttpClient [139771015977088] Response body length: 230__

tcpdump shows that S3 server response correct. It's the library fails to parse the response:
Response body looks like below:

2016-09-19T08:25:49.000Z"2db0c8febc53ec3f01e740dfac41da8a"

The bug is here: "CopyPartResult" is exactly the root element of the XML document, instead of a child node under root.
UploadPartCopyResult& UploadPartCopyResult::operator =(const AmazonWebServiceResult& result)
{
const XmlDocument& xmlDocument = result.GetPayload();
XmlNode resultNode = xmlDocument.GetRootElement();
if(!resultNode.IsNull())
{
XmlNode copyPartResultNode = resultNode.FirstChild("CopyPartResult");
if(!copyPartResultNode.IsNull())
{
m_copyPartResult = copyPartResultNode;
}
}

@allspace Do you still have this bug in your project?

I can see the Etag in current log, reopen if the issue remains


[WIP] Desktop interface

This creates the Desktop interface. Currently the following functionalities have been implemented

Wallet Balance
Transaction List
Generate Address and corresponding QR image

The send page and it's functionalities are in a WIP state.

I did a very preliminary run-through of the code. I'd like to keep the focus on getting this PR to a state where the functionalities and usability are "okay enough" before taking a deeper dive into the code base. We can always optimze the code later; and we will. For now, let's build something that works and works well.
I'll share observations and recommendations as I test the desktop app more.


More source unit tests

After #110 we have unit tests covering a fairly large number of cases for source configurations, but its missing some things:

The docker image source with cmd supports mounting another source spec in.
The Build source only tests inline dockerfiles
i. We can even drop the inline field after #98
ii. Probably we have this test too tightly coupled with the actual dockerfile format (its using dockerfile2llb to convert a literal dockerfile to llb). Even though the source type is for building a dockerfile, that implementation is outside the scope of what we are testing and we can probably just stub out the implementation and make sure that the correct function to forward the request to buildkit is being called.

I am going to add basic unit tests for source spec mounting for docker image with cmd in #117


split data and link

In this PR I split the data and the link. I added getters and setters on TraceLink and TraceLinkBuilder to reflect that. Otherwise the change is fairly straight forward in the Sdk.

This change is

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


File saving button

click on button to save the image/video comparison
Seems like video is more complex to implement: What if the user wants to contol comparison method?

Windows: https://stackoverflow.com/questions/34322132/copy-image-to-clipboard

bind_copy_cmd = "" if platform.system() == "Darwin" else ""

Linux: https://stackoverflow.com/questions/67356520/how-to-copy-a-file-image-to-the-clipboard-in-linux-using-python


Update: Ultimaker.Cura version 4.8.0

- [X] Have you signed the Contributor License Agreement?

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

btw it has a issue where the drivers for the program don't load silently so it will fail
#https://github.com/microsoft/winget-pkgs/pull/23391

btw it has a issue where the drivers for the program don't load silently so it will fail ##23391

I believe that only effects versions newer than 4.8.0, otherwise the manifest wouldn't have made it into the repository in the first place.


Pornhub upsell fix

Category
This change is exactly one of the following (please change [ ] to [x]) to indicate which:

[x] a bug fix (Fix #1288, Fix #1329)
[ ] a new Ripper
[ ] a refactoring
[ ] a style change/fix
[ ] a new feature

Description
Download was failing on some Pornhub videos due to the upsell format being used.  These are blank unless you pay for them.  Fix was to ignore any quality entries that had the upsell format.
Testing
Required verification:

[x] I've verified that there are no regressions in mvn test (there are no new failures or errors).
[x] I've verified that this change works as intended.

[x] Downloads all relevant content.
[x] Downloads content from multiple pages (as necessary or appropriate).
[x] Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.

[x] I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

[ ] I've added a unit test to cover my change.

Add a warning for the user when the download has to be skipped
Something like
sendUpdate(RipStatusMessage.STATUS.DOWNLOAD_ERRORED,
                    "Could not download paid video from $url");
        }

Add a warning for the user when the download has to be skipped
Something like
sendUpdate(RipStatusMessage.STATUS.DOWNLOAD_ERRORED,
                    "Could not download paid video from $url");
        }

@cyian-1756, I'm not familiar with that function.  I would default to the logger info function unless there is a good reason not to.  Also either way, I don't want the ripper to fail because it encounters an upsell video.  I'd rather maintain expected behavior and just grab the next best resolution available.  Thoughts?

I'd rather maintain expected behavior and just grab the next best resolution available. Thoughts?

Makes sense. I assumed upsell was the only format these videos were in.


[RFC] Add a "dummy" component to the theme spec that can be customized using the styleOverrides prop

What's the problem? 🤔
In an app that uses a custom theme...
<ThemeProvider theme={myTheme}>

... a mui component combined with a user-specified class
<Card className='MyTheme summary-view'>
	...
</Card>

... can be formatted by specifying the styling in the custom theme as follows:
 const myTheme = {
  MuiCard: {
    styleOverrides: {
      root: ({ theme }) => ({
        '&.MyTheme.summary-view': {
          color: theme.palette.primary.main,
        },
      }),
    },
  },
};

The mui ThemeProvider  will generate the html & css for the "user-extended" mui components.
The combination of html and css might look something like

	...

The css selector:
.css-17bfqle.MyTheme.summary-view {
	color: rgba(...);
}

The problem
All of this functionality depends on the MuiCard hook in the now customized theme.  This can be suboptimal.

The MuiCard comes with a lot of extras.  The actual class generated is:

When problem solving a complex layout, I have to be concerned about the influence of all of the "slots -> classes" that come with the available mui components.  Even the most basic mui-component,

The container centers your content horizontally. It's the most basic layout element.

... comes with 8 slots.

I can only influence the layout where there is a mui-component (or child-of a mui-component).
I'm forced to introduce an alternative css methodology to influence the layout that does not have a clear relationship with a mui component.

Use case for MuiDiv, a mui-component with zero slots
Many layouts benefit from repeated use of div to manage layout and the dynamics therein.
  function Layout({ children }) {

  Outlet.displayName = 'Projects-Outlet';

  return (

      {children}

          <Outlet />

  );
}

There is no way to include the css spec in the custom theme.
Anything I do has the following limitations:

introduces a "new source of truth"
I cannot access the "theme"
Requires an approach outside of my custom theme

What I do now is use a my-theme.css.
.controller.outlet.flex-handle {
    flex: var(--controller-outlet-flex-handle);
    min-width: var(--main-view-min-width);
}
.controller.main.flex-handle {
  flex: var(--controller-main-flex-handle);
}
.controller.main.flex-handle.mini {
  width: var(--controller-main-mini-width);
}
.controller-mini-overlay {
    position: absolute;
    background: var(--gradient-controller-overlay);
    width: 100%;
    height: 100%;
}

A MuiDiv would allow me to instead do the following:
  function Layout({ children }) {

  Outlet.displayName = 'Projects-Outlet';

  return (

      {children}

          <Outlet />

  );
}

... leverage how I'm already thinking about the html markup
 const myTheme = {
  ...
  MuiDiv: {
    styleOverrides: {
      root: ({ theme }) => ({
        '&.controller': {
          color: theme.palette.primary.main,
		  background: theme.gradients.controller,
        },
      }),
    },
  },
};

... leverage how and where I'm already hosting my css specifications for the application over-all.
What are the requirements? ❓

Be included in hooks processed by the ThemeProvider.
Have no default values nor be influenced by other mui-classes.
Have the one root slot required to meet the minimum spec for the ThemeProvider parsing engine.
If used without any customization has no impact on the layout of the app.
Does not require implementing the css specification outside of the custom theme.
Be a dom element that can be targeted directly using the custom theme (not "in-relation" to existing mui-compoents)

What are our options? 💡
The proposed approach utilizes the current methodology for using a custom theme in the ThemeProvider.  In my understanding, all mui-component can be customized using the styleOverrides configuration option in the custom theme.  A notable exception is Box.
Existing components that utilize styleOverrides
Existing components all of have "a purpose on their own" and thus would "muddy" the intent and ability to incrementally add user-defined functionality.
Case in point,  the Container, the most basic of components, does not meet the spec.  Conceptually Div is both conceptually broader and narrower than Container.  Technically, Containerwith its 8 purpose-built slots  is more specialized.
I do not know enough about how Box with the sx and many other short-hand syntax work.  What I do know is that the ThemeProvider does not process Box the same way it does other mui components.  Furthermore, there is a lot of functionality in the Box.  Box might be considered the "opposite" of what I am proposing.  Even if it could be added to the custom theme, it may make understanding how and when to use Box confusing in context of the different performance consideration.
I imagine something like:

Both Box and Div provide a way to enable functionality the purpose-build mui components do not.  Each provide a way to add functionality outside of the purpose-build mui components.   Use Box to generate "on the fly", component-specific customization.  Use Div for adding custom functionality that can be accessed throughout the application.  Composition of functionality using Box is accomplished the same way we combine react components.  Composing Div functionality can also be accomplished by way of the className prop.

Proposed solution 🟢
Implementation may only require adding MuiDiv to what is included in what the ThemeProvider processes.   Where Box has a lot of separate functionality, Div leverages the syntax already utilized by the mui theme.
From a design perspective, I see two ways to consider the proposed Div component:
A. As the component that meets the theme spec required to generate the html and matching css, but doesn't otherwise do anything. As such, it's the missing "empty mui-component", that without customization does not impact the view nor layout (see note re span below).
B. Expand the mui-theme functionality to include regions in the DOM where the theme context is available, but is not served by a purpose-built mui-component.
Overall, much of what I'm proposing is an extension of what was once a debate regarding whether a component library should consider layout.  Material-ui, thankfully, chose to include layout components.  All of the components benefit from the ThemeProvider machinary configured using the styleOverrides prop.  There remains a gap: an empty component that the Div component proposes to fill.
Final note: span is the most neutral html element.  The proposed "empty" mui-component is conceptually more like span and thus could operate accordingly.   Either could be toggled to behave as the other; alternatively, both could be included in the revised spec.
Footnote
Feedback and corrections in my understanding of the underlying functionality are welcome.  This RFC is a draft.

I have implemented the proposal for everyone to review. The existing codebase is really nice. Extending the feature-set  with the Div component was straightforward.
With this addition in place, I don't have to consider any other theming methodology. @mui/material custom theming using styleOverrides provides a unified methodology to "theme" 100% of my react codebase, 100% of the DOM.
Most importantly,

all of my css-related code can now live in a single file (100% with access to both the owned and theme props)

I can dramatically increase the "directness" of the selectors; making for a more sensical and thus transparent design.

I expect the length of many of my selectors will be cut in half.
The reduced dependency on a single purpose-built component allows for more reuse of my compositions of css-related strategies.
The cognitive load associated with previously "contrived parenting" only to maximize the centralization of my css, is gone

I don't have to consider other methodologies - a big, big win for me. I can now exploit the power of modern css with the dynamic access to the information hosted in my apps theme manager (@mui/material).

The approach doe not impede on nor limit other methodologies.

Hey, thanks for the RFC 👍.
You can create your own themable component using the styled API.
In your case, it would look like this:
import { styled } from '@mui/material/styles';

const Div = styled('div', {
  name: 'MuiDiv',
  slot: 'root',
})({});

Then in the theme, you can style the component like what you needed:
const myTheme = {
  ...
  MuiDiv: {
    styleOverrides: {
      root: ({ theme }) => ({
        '&.controller': {
          color: theme.palette.primary.main,
		  background: theme.gradients.controller,
        },
      }),
    },
  },
};

I am closing this since it is already possible with the current stable version (v5). Feel free to reopen if you think it is not.

I did not see the link between the styles api and the theme customization. Solid.
What did you think about the generic utility of the component to “close the gap” in the mui scope?


Swift 3.0 support?

Yes, of course, as soon as it is going to be live. I just don't want to make two separate branches.


Added New Project PC-GameInfo

This Project is created on the Angular framework with the help of Rapid API,
PC-GameInfo is a game info Database Application,
All the commands and packages that are needed to run this application are given in the Readme file.
this application is responsive also.

Just rename your folder with your GitHub username and project name(eg- Harsh3341-NoteApp)

I have to create a pull request again after renaming the project?

Ya

Please check it I renamed the project.

Great, Thanks for contributing🎉


fix: improve how to get security groups, subnets and tags from machines

Users can customize the security groups, subnets and tags, this allows to
use the machines that already exists and get the security groups, subnets
and tags to deploy avoiding heuristics that could not be true.

/lgtm


Bau set sensible scaling target

There was an error in the repo this configuration was copied in from. This sets the CPU scaling value to be 70%

Im not SRE on lime, but approved because it should be a simple non breaking change

Merging to reduce un-needed instances


fix(plugin): adds the 'no-consumer' flag to the ldap plugin schema

Adds the no_consumer flag to the ldap plugin.
Issues resolved
Fixes #2235

merging this, considering @thefosk identical change as review approval


useAsyncQuery can't refresh

Environment
I came across different issues opened about what it looks to be the same problem.
I have not been able to refresh the data of useAsyncQuery in any way.
Describe the bug
useAsyncQuery only seems to work on page refresh / landing.
Expected behaviour
refresh() or watch makes no different (not sure they are even needed on route change).
Reproduction
No response
Additional context
Nuxt 3 documentation does not mention useAsyncQuery: is this actually usable in Nuxt 3?
Logs
No response

Looks like the issue might be related to the token.
After many tries I gave a go to nuxt-graphql-client instead.
While testing I made the api public and everything immediately worked.
When I tried a token to access it, I experienced the same errors on pages navigation.
This time, however, I found a retainToken option in that documentation which, added and set to true, fixed the issue.
Not sure if apollo has a similar thing, I expect it does, though I will probably stick to nuxt-graphql-client at this point.

In Addition, The result from useAsyncQuery is unable to update automatically with Apollo Cache. I had to write a custom useAsyncQuery. It is still working for me.
type Options<TResult, TVariables> = OptionsParameter<TResult, TVariables> & {
  key?: string
}

export const useAsyncQuery = async <TResult = any, TVariables extends OperationVariables = OperationVariables> (document: DocumentParameter<TResult, TVariables>, variables?: VariablesParameter<TVariables>, options?: Options<TResult, TVariables>) => {
  const { client } = useApolloClient()

  const fn = () => client.query<TResult, TVariables>({
    query: document as DocumentNode,
    variables: variables as TVariables
  }).then((res) => res.data)

  const key = options?.key || hash({ query: print(document as DocumentNode), variables })
  await useAsyncData(key, fn)

  return useQuery(document, variables as TVariables)
}

Basically, I call useAsyncData to write the result to Apollo Cache and return useQuery instead.

Indeed the refresh doesn't work at all. I am unable to refresh the data, and I see that the ref are updated, so the issue is in the refresh function.
What would be a better way to trigger a reactive action on useAsyncQuery (refreshing the data, or remaking the query), when the variables reactive change? It would be interesting if the refresh could be triggered also automatically without the need of for example clicking to trigger it.

Also experiencing this issue, I'm kinda blown away this isn't tripping everyone up. Is is just no on is using this package? What are we missing.

Also experiencing this issue, I'm kinda blown away this isn't tripping everyone up. Is is just no on is using this package? What are we missing.

Same here, this is really annoying, in nuxt2 I was refreshing my queries via EventBus after closing a modal, worked perfectly fine. With this version (alpha10 and before) I get an error saying it is undefined...

There seems to be another problem with this version. When I close my modal I get this error:
Uncaught TypeError: this.$apollo.destroy is not a function
    at Proxy.destroy (vue-apollo-option.esm.js?v=15a10614:1417:18)
    at chunk-UJJZ7LWV.js:4069:88
    at callWithErrorHandling (chunk-UJJZ7LWV.js:1552:18)
    at callWithAsyncErrorHandling (chunk-UJJZ7LWV.js:1560:17)
    at hook.__weh.hook.__weh (chunk-UJJZ7LWV.js:4049:19)
    at flushPostFlushCbs (chunk-UJJZ7LWV.js:1723:41)
    at render2 (chunk-UJJZ7LWV.js:7764:5)
    at Object.unmount (chunk-UJJZ7LWV.js:5225:11)
    at onClose (modal.js?v=15a10614:57:27)
    at callWithErrorHandling (chunk-UJJZ7LWV.js:1552:18)

This references
function destroy() {
  if (this.$apollo) {
    this.$apollo.destroy();
    this.$apollo = null;
  }
}

in vue-apollo-option.esm.js?v=15a10614.

UPDATE: @ssyberg : I just found out that reactive queries in options api are working like in nuxt2, you just have to place the apollo object after the setup routine, this is awesome !!! :) With that you can easily do a this.$apollo.queries.myquery.refresh() and everything is perfectly fine, no need for useAsyncQuery, just everything out of the box, like in nuxt2.
export default defineNuxtComponent({
  name: "MyTest",
  async setup(props) {
     .....
  },
  apollo: {
    setting: {
      query: gql`
        query ($name: String!) {
          setting(where: { name: $name }) {
            show
          }
        }
      `,
      variables() {
        return {
          name: "showNameOfSomeone",
        };
      },
      update: (data) => data.setting,
      error() {
        if (process.client) {
          this.$nextTick(() => {
            this.$buefy.toast.open({
              message: this.$t("loading_error"),
              type: "is-danger",
            });
          });
        }
      },
    },
   currentSchemas: {
      query: gql`
      .......
 },
 data() {
    return {
        ......

Understanding the Issue with "Refresh"
Discovery Process
While looking into the code and experimenting, I discovered something:
The asynchronous queries are wrapped in Nuxt's useAsyncData, which explains why we get refresh in return instead of vue-apollo's (the underlying package) refetch.
I actually discovered why it doesn't work when playing around with the caching options.
Conclusion: refresh =\= refetch
When executing the refresh method returned by useAsyncQuery it doesn't execute the refetch method from the underlying package. It just executes the function passed to the useAsyncQuery again. Which results in loading the response from cache if cache is enabled (which is enabled by default).
Solution
If you want to be able to refresh you'll need to disable the cache. Which is a bummer if you'd like to cache.
You can still enable cache by setting it true like this: (would love to have this documented)
const { data, refresh } = await useAsyncQuery({
  query,
  variables,
  cache: true // Here
})

Caveat
For some reason setting it false when cache is globally enabled does not work due to this line here which could be fixed with this PR
TL:DR
Refresh does not "refetch" when cache is enabled.

@timyourivh thanks for approach, it works! But cache is very important for optimization. Is it possible to fix?

Same issue

Hello there,
I share also my workaround, it is correctly working both for pinia store and component script setup (achieving the same desired behavior of using the official useAsyncData composable):
  async function search(input: SearchInput = searchInput.value): Promise<NormalizedSearchResponse | null> {
    try {
      const { data } = await useAsyncQuery<{ search: SearchResponse }>(
        SEARCH,
        { input } as SearchQueryVariables,
      )
      return data?.value?.search
        ? ({
          ...data?.value?.search,
          items: data?.value?.search?.items?.map((item: SearchResult) => normalizeSearch(item)) || []
        })
        : null
    } catch (err) {
      console.error(err)
      return null
    }
  }

  const searchResult = useAsyncData<NormalizedSearchResponse | null>(
    'products',
    () => search(searchInput.value),
    { watch: [searchInput] }
  )


Activity 1: Your First Caption

Using the API, I have just created a file with a random octocat for you to caption. In this activity, we will learn how to make changes to files in our GitHub repository.

[ ] @emteach
[ ] @weshockley
[ ] @ASwenson22
[ ] @BlazeFS
[ ] @IamNotQuick
[ ] @Krause94
[ ] @Nichodaemus
[ ] @Onggiverse
[ ] @ahox0019
[ ] @bkrotz
[ ] @byklearning
[ ] @czweber1
[ ] @dwolf1234
[ ] @grafix9876
[ ] @jeffpalzermn
[ ] @jvereide
[ ] @lukebrandt
[ ] @smaher1971
[ ] @tiryx007

👍
On Tue, Jan 9, 2024, 10:10 AM EmilysNest @.***> wrote:

Using the API, I have just created a file with a random octocat for you to
caption. In this activity, we will learn how to make changes to files in
our GitHub repository.

@emteach https://github.com/emteach
@weshockley https://github.com/weshockley
@ASwenson22 https://github.com/ASwenson22
@BlazeFS https://github.com/BlazeFS
@IamNotQuick https://github.com/IamNotQuick
@Krause94 https://github.com/Krause94
@Nichodaemus https://github.com/Nichodaemus
@Onggiverse https://github.com/Onggiverse
@ahox0019 https://github.com/ahox0019
@bkrotz https://github.com/bkrotz
@byklearning https://github.com/byklearning
@czweber1 https://github.com/czweber1
@dwolf1234 https://github.com/dwolf1234
@grafix9876 https://github.com/grafix9876
@jeffpalzermn https://github.com/jeffpalzermn
@jvereide https://github.com/jvereide
@lukebrandt https://github.com/lukebrandt
@smaher1971 https://github.com/smaher1971
@tiryx007 https://github.com/tiryx007

—
Reply to this email directly, view it on GitHub
https://github.com/GH-DEV-WS-MNIT/Caption-This/issues/2, or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFG76RBAZILJDCL4IV4CFGTYNVTXZAVCNFSM6AAAAABBSHS7QCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3TCNBQGY2TAMQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Broken conferences links in Videos and Podcasts section of README.md

In what area(s)?

/area docs

Expected Behavior

Generally someone who is exploring dapr runtime for the first time, will look for videos from conferences.
Currently following 2/3 conferences links are broken in Videos and Podcasts section of dapr/README.md

Dapr, Rudr, OAM: Mark Russinovich presents next gen app development & deployment
Mark Russinovich presents "The Future of Cloud Native Applications with OAM and Dapr"

Actual Behavior

Dapr, Rudr, OAM: Mark Russinovich presents next gen app development & deployment

This leads to video with title "The Future of Cloud Native Applications with Open Application Model and Dapr"

Mark Russinovich presents "The Future of Cloud Native Applications with OAM and Dapr"

This is broken and takes user to an error page.

Steps to Reproduce the Problem

Look for mentioned section in README.md
Proposal
Updating the readme file with correct links.

Dapr, Rudr, OAM: Mark Russinovich presents next gen app development & deployment
Mark Russinovich presents "The Future of Cloud Native Applications with OAM and Dapr"

Let me know if the proposal adds value, would love to raise the PR with the fix.

This is still broken @AaronCrawfis, can you take a look?


[GKE V2] Cluster stuck in updating state "Waiting for nodes"

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):
On Rancher master-head version f5393c2
Create a google cloud credential.
From GKE console, create a default k8s cluster.
From Rancher, import the cluster from the API UI.
Input cluster name and config in gkeConfig:
{
  "clusterName": "aaron-test",
  "displayName": "aaron-test",
  "googleCredentialSecret": "cattle-global-data:cc-dg229",
  "imported": true,
  "projectID": "rancher-qa",
  "region": "us-central1-c"
}

Import cluster
Result:
The cluster is provisioned successfully, but becomes stuck in updating state: Waiting for nodes
Other details that may be helpful:
This is also seen in hosted EKS V2 clusters created from the API.
EKS operator version: v1.0.1-rc6
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-head version f5393c2
Installation option (single install/HA): Single install

Tested on Rancher v2.5-head version 7426ba8
EKS operator version: v1.0.1-rc6
Tested import use case:
Imported cluster is stuck in updating state with: Waiting for nodes
Tested hosted cluster with the following gkeConfig:
gke5.json.zip
The cluster is stuck in updating state with: Waiting for nodes
The cluster is seen in GKE console with an unschedulable pod:
Problem
Your cluster has 1 unschedulable pod

Details
Unschedulable pods
calico-typha-7c595b658-x2v26

EKS operator logs:
c-85qqc - imported cluster
c-8m9j8 - hosted cluster
time="2021-04-08T17:10:03Z" level=info msg="Starting /v1, Kind=Secret controller"
time="2021-04-08T17:10:04Z" level=error msg="Error recording gkecc [] failure message: resource name may not be empty"
time="2021-04-08T17:10:18Z" level=info msg="cluster [c-85qqc] is imported, will not delete GKE cluster"
time="2021-04-08T17:21:17Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:21:17Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:21:17Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:21:47Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:22:17Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:22:47Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:23:17Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:23:47Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:24:17Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:24:47Z" level=info msg="waiting for cluster [c-8m9j8] to finish creating"
time="2021-04-08T17:25:17Z" level=info msg="Cluster aaron-gke is running"

This issue is validated on Rancher v2.5-head version d1083bc
GKE operator version: gke-operator:v1.0.1-rc6
Hosted cluster is provisioned successfully through the API.
Imported cluster is provisioned successfully through the API.

This behavior is seen on Rancher master-head version b202f20
GKE operator version: gke-operator:v1.0.1-rc6
Imported and hosted clusters are stuck updating with: Waiting for nodes
Reopening for a fix on master-head

@aaronRancher can you confirm the version of rancher-operator that's deployed? The fix is in v0.1.4-rc3:
kubectl -n rancher-operator-system get deploy rancher-operator -o jsonpath='{.spec.template.spec.containers[0].image}'
rancher/rancher-operator:v0.1.4-rc3

On v2.5-head version d1083bc:
Rancher Operator version: rancher-operator:v0.1.4-rc3
On master-head version b202f20:
Rancher Operator version: rancher-operator:v0.2.0-alpha02

@aaronRancher this should be fixed in master now with rancher-operator v0.2.0-alpha03

This issue is validated on Rancher master-head version 39d572a
GKE operator version: gke-operator:v1.0.1-rc6
Rancher Operator version: rancher-operator:v0.2.0-alpha03
Hosted cluster is provisioned successfully through the API.
Imported cluster is provisioned successfully through the API.


JSR308 style annotations require explicit @Target annotation

Reverting JDT Bug 552082-Fix the applicability of a no-@target annotation type updates, as the behavior is not compatible with JDK 11 and also with latest javac.
For jdt.core, refer to https://bugs.eclipse.org/bugs/show_bug.cgi?id=552082 for more details.
For javac, refer to https://bugs.openjdk.org/browse/JDK-8231435 and https://bugs.openjdk.org/browse/JDK-8231436 for more details.

@guw - I am still testing the change, will remove the draft state after completing the test.

@Assk Can you also open a bug at https://github.com/eclipse-jdt/eclipse.jdt.core? I'd like to better understand why this needs to be reverted. From reading through bug 552082 it looks like Stephan implemented to support Java 11. Also according to https://bugs.openjdk.org/browse/JDK-8231436 it seems javac is broken but ecj is ok?

Looks like they may already have a bug 533199 open for something similar. The part I am having trouble is https://bugs.openjdk.org/browse/JDK-8231435 says spec affected version is from JDK 13 and is resolved only in JDK 14. Here is the discussion they had for older releases: https://mail.openjdk.org/pipermail/compiler-dev/2019-September/013705.html

@Assk Can you add all this to the README as part of the PR? This keeps track of the modifications. https://github.com/salesforce/bazel-jdt-java-toolchain/blob/main/compiler/src/main/ecj/README.md


Add RangeDaily

Only the last three normal commits were intended:
refactor out RangeBase (in preparation to reuse for RangeDaily) …     9e96c6e
add RangeDaily …     9db341e
tweak formatting so log output looks consistent with parameter serial… …     b004e4a
I don't know why all the mess keeps tagging along. Ballmer peak over, will sort out tomorrow.

lgtm

Wonder if squashing necessary? Squashing the addition into the refactor would make quite an incomprehensible overhaul. I guess I could've PR'ed the refactor separately first...

I don't have strong feelings


Jakebranch

added summarize utility and USA notebook

No conflicts with main branch, merged as-is after review


Add NewConsistentHashPartitioner

Uses Google's Jump Consistent Hash function to provide consistent key -> partition hashing when a topic's partition count changes. This is for the case where topic consumers need to rely as much as possible on messages with specific keys arriving in order by staying on the same partition even when the topic's partition count changes.

Thanks for the contribution, but I'm a bit confused why you can't just pass the custom hash function into the existing hash partitioner?

Hmm. Should've read the code better. You're right. Also it appears my concern about thread safety with hashPartitioner calling hasher.Reset, Write is also invalid as msgs are passed through a channel/goroutine. I'll close this.

Sorry for the noise. It appears that simply using NewCustomHashPartitioner and passing in a custom hash.Hash32 won't work. The consistent hashing function needs to know the number of partitions to hash against. See func jumpHash(key uint64, numBuckets int) int32 in this PR.
I can redo this PR to remove the thread-safety change for calling hasher since it's not needed by the way SyncProducer calls the partitioner. Let me know what you think.

Yes, please undo the thread-safety changes. We don't need them and it is more efficient to reuse a single hasher.
Good point about the need for the number of partitions. Based on your actual implementation here, the jump hash isn't even the underlying hash algorithm (that's FNV64), it's yet another way of doing the modulus/abs-value, so I think it could still be implemented as an additional option call on the existing hash partitioner?

It could be done that way. We'd need to change/add this..
func NewCustomHashPartitioner(hasher func() hash.Hash32) PartitionerConstructor {
to something like this...
func NewCustomHashPartitioner2(hasher func() hash.Hash32, makeConst func(hash uint32, partitions int) uint32) PartitionerConstructor {

No, I think you can just add a method conforming to HashPartitionerOption and then add it to a call to NewCustomPartitioner.

Maybe I'm missing something. But I don't see how it's possible to implement consistent hashing without changing the code somewhere. To me it fundamentally looks like hashPartitioner.Partition(message, partitions) needs to be made to call -some- method that takes both the message key (or its bytes) and the number of partitions in order to determine a partition number.

Oh yes, you'll have to change the internals of hashPartitioner.Partition a bit to make this work; I was focusing on what the external API changes would look like.

ok. will try to put something together when I can get time. Closing this for now