Error: Redirected from X to Y via a navigation guard.

Version: 3.3.2
https://github.com/vuejs/vue-router/blob/1f3aea660804bd9dfba3020e2d112d9bd510e518/src/history/base.js#L178
I have a Navigation Guard that does some various checks and redirects when necessary. Vue-router is not throwing this error when I do. Though everything is still working fine.
Is there a reason why this error is being thrown? What is the "correct" way to redirect via a navigation guard?

You probably redirecting correctly (next('/new-location')) although I can't tell without code. The errors have been exposed for a while now (see https://github.com/vuejs/vue-router/releases/tag/v3.1.0) and now we are making them real errors with properties so people can control what to do with navigation failures : https://github.com/vuejs/rfcs/pull/150 (v4)

Thanks for replying. The issue getting closed right away with the link to the issue creator really annoyed me. :)
After looking at the latest commits I saw that the error message will be updated to say that the router was being redirected while in the process of being redirected. That helped me figure out what was going on with my code.
On Jun 6, 2020, 2:36 PM +0300, Eduardo San Martin Morote<EMAIL_ADDRESS>wrote:

You probably redirecting correctly (next('/new-location')) although I can't tell without code. The errors have been exposed for a while now (see https://github.com/vuejs/vue-router/releases/tag/v3.1.0) and now we are making them real errors with properties so people can control what to do with navigation failures : vuejs/rfcs#150 (v4)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks for replying. The issue getting closed right away with the link to the issue creator really annoyed me. :)

I understand but do take the time next time to read what we write down please. We have put that there for a reason

I see the comment now on the New Issue form. Not sure how I missed it the first time.
It could also help to have a JSFiddle starter template specifically for vue-router. I was looking at trying to create a simple example to demonstrate the issue and didn’t really know how to get it started with a fiddle.
Thanks for your time. Have a great day!
On Jun 6, 2020, 3:54 PM +0300, Eduardo San Martin Morote<EMAIL_ADDRESS>wrote:

Thanks for replying. The issue getting closed right away with the link to the issue creator really annoyed me. :)
I understand but do take the time next time to read what we write down please. We have put that there for a reason
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Sorry, why do you need a fiddle to see that your code is logging an error for doing something that's part of intended behaviour and backed by your own documentation?
In your code there is an intended exception issued whenever a guard is using next handler for replacing intended navigation target with a different one. But even then the redirection is performed. Maybe this exception is required to properly abort any ongoing transition in favour of a new one started. But this looks like an internal design/API issue of vue-router.
Next, there is your manual listing this scenario as a use case.  I can't see any note there on having to live with an error logged to console on an unhandled promise rejection each time I use a guard for what it is intended for in many scenario by assuring prerequisites met prior to entering a route.
So, if this is intended behaviour, would you please elaborate on why dropping one routing target in favour of another one via guard is worth an error? And please add some information to the manual for that use case is anything but comprehensible by reading those docs.

In addition: this error is currently breaking SSR side of VuePress build script. I expect currently given example for integrating vue-router with SSR is broken as well just because of this error on behalf of vue-router.

Ok, AFAICT the 3.2.0 release of vue-router has introduced some breaking change of API thus failing to comply with semantic versioning.

I've created a test project in https://github.com/soletan/vue-router-test.

git checkout 0c5d
yarn install --frozen-lockfile
npm run build

This will fail. Next

git checkout HEAD
yarn install -frozen-lockfile
npm run build

This time it will succeed. The change is about forcing VuePress to use vue-router 3.1.6 instead of 3.4.3.
Basically, I'm aware that there might be an issue with VueJS SSR doing something undocumented which is eventually causing this issue. But right now all I can see is that some software using vue-router was working fine at least until version 3.1.6 and stopped working in latest version. I haven't tested all the versions in between for sure. The release following 3.1.6 was 3.2.0, a minor release, thus expected to stay backward compatible. And this release was introducing changed behaviour in handling errors on redirecting routing transitions.

You probably redirecting correctly (next('/new-location')) although I can't tell without code. The errors have been exposed for a while now (see https://github.com/vuejs/vue-router/releases/tag/v3.1.0) and now we are making them real errors with properties so people can control what to do with navigation failures : vuejs/rfcs#150 (v4)

I'd like to control to ignore those errors. This kind of control is out of scope for you, isn't it?

(@posva haven't heard any updates on provided demonstration for the so called false alarm, would you mind sharing your 50 cents with me on this issue.)
Here is my sort final note on this issue:

https://jsfiddle.net/rypowk94/ is reproducing the mentioned behaviour when clicking on button visible after going to Foo. This fiddle is actually relying on programmatic API as suggested for SSR or vue-router's own documentation. In case of the latter link, the remarks there are using phrases like "optionally provide", "you can omit" and "return a Promise, if supprted" ... sounds quite open-minded with lots of conditionals trying to express interest in different possible use cases. However, it should present a big red box promoting the imminent need for handling router issues, mostly in context of SSR or VuePress, but eventually with any application.

The issue is obviously due to router.push() changing its API in a non-backward-compatible way when it starts throwing exceptions. As given in documentation linked before, this change started in 3.1 which is a minor revision and should be backward-compatible. API reference and documentation on programmatic navigation are indicating support for either providing callbacks or accepting promise returned. However, this documentation is still ambivalent for it's covering a third case:
router.push(location, onComplete?, onAbort?)
router.push(location).then(onComplete).catch(onAbort)

The first signature indicates opportunity to use push() without any callback and without handling a promise returned. From a technical point of view this isn't possible for sure. However, you could add support for some options here or in router construction to adjust this behaviour.
Eventually, one eligible use case of "fire-n-forget" isn't included with this API. I don't know if it has been included properly before. Requiring to handle outcome of every intended change of route is a limitation probably causing unnecessary code in several cases. This is something new to me in context of VueJS for it is mostly favourable for its highly concise syntax. Otherwise I could stick with Angular or even Java and build huge non-DRY applications for ages ...
Eventually, you as a visitor might stumble over this issue in context of an existing software just like me. If you don't get any support from either team you can always rely on the power of Javascript by simply patching/hacking original push() method of router instance. Only requirement: you need access on created router instance.
const originalPush = router.push;
router.push = function( ...args ) {
	return originalPush.call( this, ...args ).catch( error => {
		if ( error ) {
			console.warn( `consumed router exception: ${error}` );
		} else {
			console.warn( `consumed unknown router exception ${new Error().stack.replace( /^[\s\S]+?at/, "at" )}` );
		}
	} );
};

This isn't a solution. It isn't clean code either. But it's fixing the issue at hand.

I checked your repros and the issue you opened on vuepress. Here is an explanation of the whole thing as well as a way to have the behavior that exists in Vue Router 4 https://github.com/vuejs/vue-router/issues/2881#issuecomment-520554378.
The reproduction using VuePress seems to have a different issue, not related (or directly related) to the Router. It's a ReferenceError when bundling on SSR.
I haven't even taken long to answer, it was one week. We were busy releasing Vue 3 and synchronizing things, but I don't have to justify anything to you anyway. The problem is that your comments are lacking basic empathy towards me as a maintainer and it's simply not worth my mental health to deal with that kind of negative comments just to send you the existing resources as I did above.
I hope you take this into account when interacting with open source maintainers in the future.


Llama v2 support

I'm sure this is the obvious question, so sorry if this is a duplicate. Raw format for Llama-v2 cannot be loaded out-of-the box:
from llama_cpp import Llama
llm = Llama(model_path="/Users/rlm/Desktop/Code/llama/llama-2-7b-chat/consolidated.00.pth")

Result:
AssertionError                            Traceback (most recent call last)
Cell In[2], line 1
----> 1 llm = Llama(model_path="/Users/rlm/Desktop/Code/llama/llama-2-7b-chat/consolidated.00.pth")

File ~/anaconda3/lib/python3.10/site-packages/llama_cpp/llama.py:305, in Llama.__init__(self, model_path, n_ctx, n_parts, n_gpu_layers, seed, f16_kv, logits_all, vocab_only, use_mmap, use_mlock, embedding, n_threads, n_batch, last_n_tokens_size, lora_base, lora_path, low_vram, tensor_split, rope_freq_base, rope_freq_scale, verbose)
    300     raise ValueError(f"Model path does not exist: {model_path}")
    302 self.model = llama_cpp.llama_load_model_from_file(
    303     self.model_path.encode("utf-8"), self.params
    304 )
--> 305 assert self.model is not None
    307 self.ctx = llama_cpp.llama_new_context_with_model(self.model, self.params)
    309 assert self.ctx is not None

AssertionError:

Anyone have linked to converted files?

Fyi, TheBloke already converted & uploaded the model: https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGML -> works for me ^^

Oh, cool. I Will check there.

@rlancemartin let me know if those models work out of the box, I'm currently working on some changes to better support the chat models (I think there's some changes that need to be made to tokenization)

@rlancemartin let me know if those models work out of the box, I'm currently working on some changes to better support the chat models (I think there's some changes that need to be made to tokenization)

Ya, it did. Pretty cool. I added an example here:
# Make sure the model path is correct for your system!
llm = LlamaCpp(
    model_path="/Users/rlm/Desktop/Code/llama/llama-2-7b-ggml/llama-2-7b-chat.ggmlv3.q4_0.bin",
    input={"temperature": 0.75, "max_length": 2000, "top_p": 1},
    callback_manager=callback_manager,
    verbose=True,
)

Anyone loaded TheBloke/Llama-2-70B-Chat-GGML successfully?

Anyone loaded TheBloke/Llama-2-70B-Chat-GGML successfully?

yep. this one to be precise: https://huggingface.co/TheBloke/Llama-2-70B-Chat-GGML

yep.

Would you mind sharing your hardware setups etc..? thanks


Implement run fusion directly in Anserini

@DanielKohn1208 and @wu-ming233 might be interested in looking at fusion. Using this thread to track progress.
Starting point: https://link.springer.com/chapter/10.1007/978-3-030-99736-6_41
@cadurosar has some code here: https://github.com/castorini/anserini/pull/2355

A very long time, I implemented all fusion algorithms on top of Lucene, voting-framework,  I am happy to work on this. I have a plenty of time to do it.

Hi @aalbahem that would be welcomed! Please email me and we can start a thread on it.

Hi @aalbahem that would be welcomed! Please email me and we can start a thread on it.

@lintool Not sure how I can email you about this, do you have slack channel for these discussion or a public email? Otherwise, we can keep the discussion here.
It has been a while since I touched anserini code, almost 3 years ago, as I was doing my PhD. Is the intention to do this in python or Java? If you like, I can hit the ground running.

@aalbahem please email me and I'll get you invited to our Slack channel.

@lintool<EMAIL_ADDRESS>


Issue 279

Address issue 279

Added "name" attribute to Sanctuary modifiers
Updated filters for Sanctuary cards

Bonus fix:

Resolved multiple copies of Sanctuary cards special modifiers loading every time Crimson Scales is added

Great, thank you :)


Implement Bitplane Representation of Quantum Images

Implementing Bitplane Representation of Quantum Images Module for hacktober fest
Linked to #31

Hi, incase you are looking for material on the chosen image representation method, you can refer to this paper: Hai-Sheng Li, Xiao Chen, Haiying Xia, Yan Liang, and Zuoshan Zhou. A Quantum Image Representation Based on Bitplanes. IEEE Access, 6:62396–62404, 2018. https://inspirehep.net/literature/2707463

thanks I've gone through the paper!


add example of Graph viz to R documentation

@pommedeterresautee  Please remove the html files from the PR as the generated md file is sufficient and will be translated to http://mxnet.readthedocs.org/en/latest/R-package/fiveMinutesNeuralNetwork.html
Possibly need a rebase http://mxnet.readthedocs.org/en/latest/contribute.html#how-to-combine-multiple-commits-into-one

@pommedeterresautee Any updates on this? I will merge this after the html file get removed

I think it s done


Displayed paths in generated output files should not be absolute

When executing a test suite or generating test documentation the full qualified path to the related source files is exposed.
This become a problem when sharing this output in issue reports (or anywhere else), because this paths may contain sensitive user/system information.
As far as I can see the href-paths itself are already relative. E.g. testdoc generates them like:
<fullQualifiedPath>/Test.robot

It would be nice if the display text could be reduced to most common root-directory or to the execution dir.
E.g. executing in dir <rest of path>/mytests/ will give displayed source paths as <a href="<whateverRealtivePath>/Test.robot">mytests(/<subdirs>)*/Test.robot
I hope I could express myself clear enough😊
P.S. I know this will not avoid the case where inputs and outputs have nothing in common or only the sensitive part. But from my perspective this is more a usage problem😉

I don't think this is a good idea for the following reasons:

It's true that paths may contain sensitive information, but just showing relative paths doesn't fully avoid that problem. There could be sensitive information in the visible part anyway.
Relative paths can be ambiguous.

In other words, this change wouldn't fully fix the problem but would make usability worse. If you are concerned about sensitive information in outputs files, you can use e.g. --prerebotmodifier to remove it regardless where it is used.


Create linter baseline file for azure-sdk-for-js.

Create linter baseline file for azure-sdk-for-js. See parent issue for full details.
Parent Issue: azure/azure-sdk-tools#7122

The linter pipeline was enabled and the baseline file was added as part of this PR


Add common service for logging deprecated api usage

For #88391
Adds a new ExtHostApiDeprecationService. This service logs a warning and telemetry when a deprecated API is used.
Updates some of the more simple deprecated apis to use this new service

This change doesn't cover deprecations for methods such as TextDocument.show() or constructors such as Task.
The reason is that I do not know how to get the calling extension information info in the implementation code

For the tasks constructor, I could mark the task as having been created using deprecated api, then in the extHostTaskService when reading tasks use IExtensionService to find the extension based on the task definition.

@alexr00 I think you may also run a problem getting access to the deprecation service inside the task constructor. If you know some way to workaround this, feel free to give it a try


Research and Choose Implementation Approach

Research and Implementation Approach:
Module Federation:

Description: Module Federation is a feature introduced in Webpack 5 that allows different JavaScript applications to dynamically share code at runtime.
Advantages:

Enables dynamic loading of microapps, making it suitable for your requirement of loading microapps at runtime.
Supports decentralized hosting, as microapps can be developed and deployed independently.
Facilitates sharing of resources and dependencies between microapps.

Implementation Steps:

Research Webpack 5's Module Federation feature and understand its capabilities and limitations.
Experiment with setting up a basic Module Federation configuration within a Next.js application.
Explore how microapps can expose components and functionalities as federated modules.
Investigate methods for integrating Module Federation with a custom registry for storing microapp metadata.

Custom Registry and Loader System:

Description: Develop a custom registry and loader system to manage the registration and loading of microapps within the Next.js application.
Advantages:

Provides flexibility to tailor the registry and loader system according to specific project requirements.
Allows fine-grained control over how microapps are registered, searched, and loaded.
Offers the potential for implementing security measures and authentication mechanisms.

Implementation Steps:

Design a schema for the microapp registry, including metadata such as name, version, entry point, etc.
Develop an API or service for microapps to register themselves with the registry.
Implement a loader mechanism within the Next.js application to fetch microapp metadata from the registry and load them dynamically.
Ensure robust error handling and security measures to validate and authenticate microapp requests.

Evaluation of Alternatives:

Single SPA: Consider Single SPA as an alternative approach for micro frontend architecture.

Evaluate its compatibility with Next.js and its suitability for dynamic loading and decentralized hosting.
Compare the features and capabilities of Single SPA with Module Federation and custom registry/loader systems.

Proof of Concept:

Research and Experimentation:

Conduct experiments to compare the feasibility and performance of Module Federation versus a custom registry and loader system.
Build a proof of concept to demonstrate dynamic loading of microapps within the Next.js host application using the chosen approach.
Gather feedback from stakeholders and iterate on the implementation based on the results of the proof of concept.

Next Steps:

Begin by researching Module Federation and custom registry/loader systems in more detail.
Conduct experiments and build prototypes to assess the feasibility and suitability of each approach within your Next.js application.
Based on the research and experimentation, choose the most appropriate implementation approach for your microapp architecture.
Proceed with implementing the chosen approach and refining it based on feedback and further testing.

Update on Research Findings:
After conducting thorough research into our current technology stack and compatibility requirements, it's apparent that the proposed solution utilizing Module Federation may not be feasible at this time. Here's a summary of our findings:

Compatibility Limitations:

Our current setup relies on Next.js 14, React, TypeScript, and Tailwind CSS with the new App Router.
Unfortunately, Module Federation is not compatible with Next.js 14, and integrating it with our stack would require significant adjustments or upgrades.

Hosting Constraints:

Additionally, considering our hosting environment on Vercel, which may have limitations or constraints that impact the implementation of Module Federation, it further complicates the integration process.

Alternative Solutions:

While Single SPA is not compatible with Next.js, it's essential to explore alternative approaches that align with our technology stack and hosting environment.
Investigating custom solutions for dynamic loading and microapp management within the constraints of our current setup could be a more viable path forward.

Next Steps:

Given these constraints, we need to reassess our approach to microapp architecture and explore alternative solutions that are compatible with our existing stack.
I suggest we focus on refining our current architecture to accommodate dynamic loading and microapp management within the constraints of Next.js 14 and our hosting environment on Vercel.

Let's discuss further and explore alternative strategies to achieve our goals while ensuring compatibility and feasibility within our current setup.

Small-Scale Refinement of Microapp Architecture for Next.js Application
Issue Description
Let's prioritize a small-scale approach for the initial version of our microapp architecture to avoid over-engineering and complexity. This issue aims to refine our current architecture to support dynamic loading and microapp management within the constraints of Next.js 14 and our hosting environment on Vercel. We'll employ lazy loading techniques and encapsulate each app as an isolated component, with the objective of later refactoring into a full-fledged microapps ecosystem.
Requirements

Refinement of Current Architecture:

[ ] Evaluate the current architecture and identify areas for refinement.
[ ] Determine the best approach for integrating lazy loading and dynamic loading techniques into the architecture.

Dynamic Loading Implementation:

[ ] Implement dynamic loading functionality to enable the loading of microapps at runtime.
[ ] Ensure compatibility with Next.js 14 and verify functionality within the Vercel hosting environment.

Encapsulation of Microapps:

[ ] Develop a strategy to encapsulate each microapp as an isolated component within the architecture.
[ ] Implement encapsulation techniques to maintain separation and modularity between microapps.

Documentation and Knowledge Sharing:

[ ] Document the refined architecture, including the implementation of lazy loading and encapsulation techniques.
[ ] Share knowledge with the team through documentation, workshops, or internal presentations.

Tasks

[ ] Evaluate current architecture and identify areas for refinement.
[ ] Research and select appropriate lazy loading techniques compatible with Next.js 14.
[ ] Implement dynamic loading functionality to load microapps at runtime.
[ ] Develop encapsulation strategies to isolate each microapp as a component.
[ ] Test the implemented features within the Vercel hosting environment to ensure compatibility.
[ ] Document the refined architecture and share knowledge with the team.
[ ] Iterate based on feedback and refine the implementation as needed.

Technical Analysis: Refinement of Current Architecture
1. Evaluation of Current Architecture:

Objective: Assess the existing architecture to identify strengths, weaknesses, and areas for improvement.
Tasks:

Review the current codebase, including components, routing, and state management.
Identify any performance bottlenecks or architectural patterns that may hinder scalability.

Evaluate the modularity and reusability of components to determine their suitability for encapsulation.

2. Integration of Lazy Loading and Dynamic Loading Techniques:

Objective: Determine the best approach for incorporating lazy loading and dynamic loading capabilities into the architecture.
Tasks:

Research various lazy loading techniques compatible with Next.js 14, such as code splitting and dynamic imports.
Evaluate the benefits and trade-offs of different dynamic loading strategies, including Module Federation and custom loader systems.
Consider how lazy loading and dynamic loading can be integrated into the routing and navigation structure of the application.

3. Dynamic Loading Implementation:

Objective: Implement dynamic loading functionality to enable the loading of microapps at runtime.
Tasks:

Develop a mechanism for registering microapps dynamically within the application.
Implement logic to fetch microapp metadata from a central registry or API.
Dynamically import microapp components and assets using lazy loading techniques.
Ensure error handling and fallback mechanisms are in place for failed microapp loading.

4. Compatibility and Testing:

Objective: Ensure compatibility with Next.js 14 and verify functionality within the Vercel hosting environment.
Tasks:

Conduct thorough testing to verify the compatibility of dynamic loading features with Next.js 14.
Deploy the updated architecture to the Vercel hosting environment and validate its behavior in a production-like setting.
Perform performance testing to measure the impact of dynamic loading on page load times and resource utilization.

5. Encapsulation of Microapps:

Objective: Develop a strategy to encapsulate each microapp as an isolated component within the architecture.
Tasks:

Define a clear boundary between microapps and the host application to enforce encapsulation.
Implement encapsulation techniques such as component composition, context isolation, or sandboxing.
Ensure that each microapp operates independently and does not interfere with other parts of the application.
Establish communication channels and boundaries for interaction between microapps and the host application.

Conclusion:
The technical analysis provides a roadmap for refining the current architecture to support dynamic loading and microapp encapsulation. By evaluating the existing architecture, integrating lazy loading and dynamic loading techniques, ensuring compatibility, and implementing encapsulation strategies, we can create a flexible and scalable microapp architecture within the constraints of Next.js 14 and the Vercel hosting environment.


Add styledText features

Users can input text in markdown format, more info: https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png
A rich text editor was added for boxes where users input text, so they can see how their message will be before they click on 'submit'
Solved merge conflicts between Images Pt1 and this feature

I noticed a couple of issues:

aboutMe text box doesn't replace image url's for html (this was the feature added for images pt 1)
also, when users want to enter images in markdown style: text , it doesn't work because the url is parsed into html first.

I'll post both if these issues once this has been merged to master :)


TitleStream: Increase long-press target size.

Here's what the inspector shows for the touchable area after this change:

I got there by doing this:

Shake gesture
"Show inspector" on the dev menu
"Touchables" in the inspector panel
Then either shake and "Hide inspector", or unselect "Inspect" from the inspector panel

Ah, good thought checking that. Certainly the ideal behavior would be for the touchable area to go the full height of the app bar.
If that seems tricky it doesn't need to block this PR (the PR is already an improvement in the same direction), but it'd be a good followup.

Added a commit to increase the size of the touchable area to the full with of the navbar, and fixed the bug that @chrisbobbe pointed out. Ready for another review!

@chrisbobbe ready for another reveiew :)

@chrisbobbe I thought about this a bit more, and realized that the height: 100% solution makes more sense — this PR as it was before broke the PM screen, since that was no longer centered. In general, it seems cleaner to fix the stream title bar by just editing its file, rather than also changing a bunch of other stuff.

this PR as it was before broke the PM screen, since that was no longer centered

Good catch, thanks! Merged, to help along this improvement for topic/stream narrows. This has also moved my thinking forward on that flexbox approach; see below.

In general, it seems cleaner to fix the stream title bar by just editing its file, rather than also changing a bunch of other stuff.

I think the rightness or wrongness of those follow-on changes could reasonably be considered a factor. Often, I'll end up doing some one-time independent cleanups alongside more targeted changes. 🙂 TitlePrivate is in a very similar situation to TitleStream, and is left without its height (and so its touch target) expanded after this PR; see screenshots. An approach like alignItems: 'stretch' in ChatNavBar wouldn't centralize the logic for vertically centering the title (a justifyContent: 'center' in TitlePrivate could do that, as you've done in TitleStream), but it would centralize the logic for expanding its touch target, and I think ChatNavBar could reasonably be the thing that controls that. That kind of advantage, if it is an advantage, is more accessible when flexbox is used, and React Native promotes flexbox as a sensible way to do layout. They also specifically prefer flex over percentage dimensions (different doc): "If you want to fill a certain portion of the screen, but you don't want to use the flex layout, you can use percentage values in the component's style."

My takeaway is that I/we could helpfully take note, as we go, on where flexbox vs. percentage dimensions really shine for us and should definitely be preferred in principle. As I've said in an earlier comment, I'm not hoping to use flexbox uncritically everywhere. But it can have some benefits that are harder to get without it. 🙂


Guest avatars have an invalid snapshot

I think this is not happening anymore. Let's reopen it if this happens again.


tests: auto \retest all PRs

Description
This PR introduces auto-retesting for all PRs targeting master. Previously, this was an opt-in feature, but it will now be automatically enabled for everyone. To opt out of auto-retesting, simply remove the auto-retest label. This change aims to help identify flaky tests and ensure tests pass eventually.
Refs:

https://github.com/stackrox/stackrox/pull/12074
https://github.com/stackrox/stackrox/pull/10635
https://github.com/stackrox/stackrox/pull/10438

[x] CHANGELOG update is not needed
[x] Documentation is not needed

Testing

[x] inspected CI results

Automated testing

[x] modified existing tests
[x] contributed no automated tests

How I validated my change
CI

We don't necessarily have a budget for CI (at least, not one that I'm aware of), but we should be vigilant about this change.
cc @stackrox/infra

What does the "bot" do to retrigger failed tests? A blanko /retest or /test name-of-failed-job? Can we teach it to retrigger GHA as well? Does it detect failed Konflux checks (we know that enterprise-contract always fails at the moment, so re-runs there would be less than ideal)?

It uses /retest. Currently it does not check on konflux nor retest GHA but we can teach it anything we want as it lives in https://github.com/stackrox/stackrox/tree/master/tools/retest

You mention that "[t]his change aims to help identify flaky tests" - how? AFAICT it hides them with retries.

Correct it hides some information but we collect tests results so we can see how many jobs filiped from red to green for the same commit.

Closing as there is not much interest in this.
@mtodor Feel free to reopen if you still think we should have it


HHH-15042: add offset-clause usage for DB2zDialect

DB2z in Version 12 and beyond supports the "offset"-clause.
Current behavior:
Hibernate uses the "fetch first ..."-clause but does not use "offset" for paging requests.
Expected behavior:
For DB2z Databases in Version 12 and beyond the dialect should use the now supported "offset"-clause
IBM Docs:
https://www.ibm.com/docs/en/db2-for-zos/12?topic=subselect-offset-clause
https://www.ibm.com/docs/en/db2-for-zos/12?topic=subselect-fetch-clause
Test:
Because there is no DB2z Docker-DB testing this comes down to testing against an z/OS DB2 Instance.
I tested it against the DB2z Instance (v12.1.0) at work without any issues.

Awesome, thanks!


Index name length

I'm wondering why it's important that the length of the index name not be different on the history table than the original table. I ask because the logic for generating the name assumes that all indexes start with index or end with _ix(\d+). This isn't the case for me, and the result is that temporal_index_name spits out the same output as the input for some of my indexes, resulting in a duplicate error when it tries to create the index.
As a workaround, I can rename my indexes, but I'm trying to understand this constraint, rather than just appending _h to the index name.

@eraffel-MDSol Given that database systems impose limits on the length of index names, I didn't want to run into situations where the index name succeeded on the base table but failed on the history table because it was too long.

To elaborate, rails can generate very long index names when you start indexing multiple columns together. It's not difficult to run into the name limits on indexes.
I'm open to ideas for solutions to your issue. Maybe add an optional config value that accepts a lambda for generating index names?


Placing fluid in bottom row of fluid filter causes a crash

Is there an existing issue for this?

[X] I did not find any existing issues.

Current Behavior
Whenever I attempt to place a fluid into the bottom row, but not the top row, of a fluid filter using a bucket of the fluid it causes a crash.
Expected Behavior
No crash
How to Test

Open fluid filter menu
click bucket onto bottom row of the fluid filter
crash a couple seconds later

Local Environment
- **Operating System**: Windows 11
- **Java version**: zulu 17.50.19
- **Minecraft Version**: 1.20.1
- **Version**: 6.1.8
- **Other Mods**: I originally found it in monifactory but even a fresh 1.20.1 instance with just enderio caused it

Any Additional Information?
crash-2024-08-05_01.39.57-client.txt

Something important I forgot to add, I don't seem to be able to load into the world after, I have to load a backup just to play the world again.

Happened to me too.
Crash report: https://bytebin.lucko.me/hFchbqEln8
Happened on the latest version of EnderIO 6.1.8-beta for 1.20.1 MC.
Happend with an Industrial Foregoing pink slime bucket.

Confirm also happened to me, also in monifactory. EIO 6.1.8-beta for 1.20.1.
Crash report


fix: DEV-3826: Toggling Audio interfaces should correctly update the view

Hi @yyassi-heartex!
This PR was created in response to a PRs in upstream repo:

https://github.com/heartexlabs/label-studio-frontend/pull/1078

this ticket was created in error


Clean Cached Derby Data #244

Signed-off-by: Paul Bastide<EMAIL_ADDRESS>

[ERROR]   WebSocketNotificationsTest.testCreatePatient:90->getEvent:63

Workflow does not yet have the testCreatePatient skip/delay


"Fix all Convert to HCL2 expressions problems in file" doesn't work

Prerequisites

[x] Ensure you have latest version of plugin installed
[x] Search for possible issue duplicates

Installation details

[x] IDE version (Help->About->Copy to Clipboard)
[x] intellij-hcl plugin version (Settings->Plugins) 0.7.5
[x] Terraform version (terraform -v) 0.12.7

IntelliJ Version details
IntelliJ IDEA 2019.2.1 (Ultimate Edition)
Build #IU-192.6262.58, built on August 21, 2019
Licensed to Gareth Jones
Subscription is active until June 22, 2020
Runtime version: 11.0.2+9-b226.7 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 1981M
Cores: 8
Registry: analyze.exceptions.on.the.fly=true, java.completion.argument.hints.internal=false, git.use.builtin.ssh=true, debugger.watches.in.variables=false, completion.stats.show.ml.ranking.diff=true
Non-Bundled Plugins: CMD Support, Key Promoter X, PsiViewer, Switch Structure, com.alayouni.ansiHighlight, com.intellij.apacheConfig, com.jetbrains.foldOtherMethods, com.jetbrains.plugins.ini4idea, com.intellij.plugins.watcher, lermitage.intellij.battery.status, mobi.hsz.idea.gitignore, net.seesharpsoft.intellij.plugins.csv, net.vektah.codeglance, org.asciidoctor.intellij.asciidoc, org.elixir_lang, org.intellij.plugins.hcl, Karma, com.dmarcotte.handlebars, com.intellij.lang.jsgraphql, com.intellij.plugins.html.instantEditing, com.intellij.plugins.webcomponents, com.jetbrains.lang.ejs, com.jetbrains.plugins.jade, com.jetbrains.php, com.jetbrains.php.blade, com.jetbrains.php.drupal, com.jetbrains.php.wordPress, com.jetbrains.twig, de.espend.idea.laravel, net.king2500.plugins.PhpAdvancedAutoComplete, cucumber-javascript, intellij.prettierJS, org.intellij.scala, org.jetbrains.plugins.go, org.jetbrains.plugins.phpstorm-remote-interpreter, org.jetbrains.plugins.vagrant, org.jetbrains.plugins.vue, Dart, org.jetbrains.plugins.node-remote-interpreter, Pythonid, com.emberjs, com.raket.silverstripe, org.jetbrains.plugins.ruby, jones.foldtestblocks.fold-test-blocks, org.psliwa.idea.composer, org.sylfra.idea.plugins.linessorter, org.toml.lang, org.rust.lang, ru.adelf.idea.dotenv, uk.co.ben-gibson.remote.repository.mapper

Terraform Configuration Files
data "aws_caller_identity" "current" {}

output "account_id" {
  value = "${data.aws_caller_identity.current.account_id}"
}

output "caller_arn" {
  value = "${data.aws_caller_identity.current.arn}"
}

output "caller_user" {
  value = "${data.aws_caller_identity.current.user_id}"
}

Taken from the aws_caller_identify page.
Exception
None, nor anything in the logs.
Expected Behavior
All interpolations are replaced w/ HCL2 expressions.
Actual Behavior
Nothing.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:

Place cursor on interpolation
Invoke "Fix all Convert to HCL2 expressions problems in file"

Looking in YouTrack, seems this is b/c of IDEA-219650

Yes, that's a problem in IntelliJ core itself :(

IDEA-219650 for everyone's convenience. Also, if you have a YouTrack account, you can vote with the thumbs up and star the issue to receive updates on its progress


Disabled customer response - responded on field in order lockdown date stamp

Description of change
Currently, Export Win admin team has an access to modify a customer date response. As requested, it must be lockdown in order not to tamper the date stamp of customer response date.

Checklist

[X] Has this branch been rebased on top of the current main branch?

Explanation
The branch should not be stale or have conflicts at the time reviews are requested.

[X] Is the CircleCI build passing?

General points

Other things to check

Make sure fixtures/test_data.yaml is maintained when updating models
Consider the admin site when making changes to models
Use select-/prefetch-related field lists in views and search apps, and update them when fields are added
Make sure the README is updated e.g. when adding new environment variables

See docs/CONTRIBUTING.md for more guidelines.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.40%. Comparing base (0125b4e) to head (148f2db).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5469   +/-   ##
=======================================
  Coverage   96.40%   96.40%
=======================================
  Files         951      951
  Lines       22494    22495    +1
  Branches     2021     2021
=======================================
+ Hits        21685    21686    +1
  Misses        658      658
  Partials      151      151

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix behavior where packets leave node if there are no backends

This PR resolves an issue where an outgoing packet destined for a service will not be dropped if it does not have any backends. Currently we will not return the service if there are no backends for it, causing https://github.com/cilium/cilium/blob/58e4081c3c2a6e052d7c5e3443be33dd6ae5024b/bpf/bpf_lxc.c#L1254-L1266
To never be run, meaning we will never drop a packet in this case and instead simply route it through the kernels default routes.
Let me know if there is anything I am missing here, I think this is the behavior of kube-proxy and other CNI's.
Fixes: #21453
Signed-off-by: Michael Aspinwall<EMAIL_ADDRESS>

Hi @michaelasp, thank you for the fix! Agree that dropping (DROP_NO_SERVICE) such a packet would be the expected behaviour.
But walking down the code a bit further, I'm surprised that this change is sufficient - don't we need to catch the svc->count == 0 case in lb4_local() now?
For the record, I think there's three paths to consider:

bpf_lxc.c (from-container)
nodeport_lb4() / nodeport_lb6(), from-external)
bpf_sock.c (socket LB)

Have you looked into adding a test for this issue?

/test

Hey @julianwiedmann! I was testing this locally and it seemed like it was enough to change the behavior in tcpdump when I created a service. When I had a service before I would see stray packets when I tried to [ing it from a pod even when it had no backends, afterwards it was correctly dropping the packets, meaning it never even showed up in tcpdump. I'll add some tests for this and look into this more. Thanks for the quick response!
I think the reasoning behind this is that if lb4_local() sees svc->count == 0 it returns an error, dropping the packet in the process while lb4_lookup_service() simply returns NULL, allowing us to keep going on in the code rather than returning an error.

I think the reasoning behind this is that if lb4_local() sees svc->count == 0 it returns an error, dropping the packet in the process while lb4_lookup_service() simply returns NULL, allowing us to keep going on in the code rather than returning an error.

:100:, and this certainly feels like the right way to fix it!
My concern is whether all paths in lb4_local() can suddenly deal with a svc->count of 0, or whether it's better to fence this right at the beginning. The semantics here for instance are not exactly trivial:
https://github.com/cilium/cilium/blob/61d7ff0083f40cc620990d96e1bf50c3e074d5c1/bpf/lib/lb.h#L1541-L1544
https://github.com/cilium/cilium/blob/61d7ff0083f40cc620990d96e1bf50c3e074d5c1/bpf/lib/lb.h#L1278-L1287

bpf_sock.c definitely needs a closer look, I'll do that tomorrow.
Re: testing - looks like https://github.com/cilium/cilium/blob/master/bpf/tests/xdp_nodeport_lb4_test.c could be adapted to cover the N/S case. And maybe https://github.com/cilium/cilium/blob/master/bpf/tests/hairpin_flow.c for the E/W path with ENABLE_PER_PACKET_LB?

I agree with that, I've only been testing the datapath for containers and while that seems to work, it may not be applicable for all other ways we handle services in cilium. This would definitely benefit from having a guard, even from a readability standpoint. Thanks for the pointers, this is my first time working with the cilium datapath code so I appreciate it :)

@michaelasp I had sent a fix for a somewhat similar issue - https://github.com/cilium/cilium/pull/20637. Does it work for you? /cc @julianwiedmann

Makes sense, I'll do something similar. I just want to make sure that by modifying lb4_local()\lb6_local()  doesn't affect any other points in the datapath. Should I wait for your change to be merged then use the same error code?

FYI, I hacked some tests for the per-packet path together here: https://github.com/julianwiedmann/cilium/tree/lb-no-backends

Makes sense, I'll do something similar. I just want to make sure that by modifying lb4_lookup_service() \ lb6_lookup_service doesn't affect any other points in the datapath. Should I wait for your change to be merged then use the same error code @aditighag ?

Hi @michaelasp , my suggestion would be the following:

ignore bpf_sock.c for now. Imho the desired behaviour is much less clear there, and its use of lb?_lookup_service() is not exactly straight-forward (with the fallback to wildcard lookup). So let's tackle that separately.
to preserve existing behaviour, push all the lookup logic into new __lb?_lookup_service() variants, and do the checks (svc->count, L7-LB etc) in lb?_lookup_service().
then use the __lb?_lookup_service() variants in the per-packet paths (bpf_lxc.c, nodeport.h), manually check the returned svc->count, and drop with DROP_NO_SERVICE. We automatically get metrics for that from send_drop_notify().
once we are confident that lb?_local() can actually handle svc->count == 0 in all its paths, we can refactor at a later time.

Awesome, thanks @julianwiedmann ! I added the changes you recommended to the pull request, thanks for the help!

@julianwiedmann Cherry picked the bpf tests and resolved comments, ptal!

Hi @michaelasp, thanks! Functionally looks good now, but please do fix up the formatting issues below.

Also see the output from the checkpatch test :o).

Fixed formatting issues, let me know if everything looks good :)

Fixed formatting issues, let me know if everything looks good :)

Some more checkpatch complaints, sorry :/.
https://github.com/cilium/cilium/actions/runs/3228467217/jobs/5284684449

Just saw those in the test failures and corrected them haha. Should be good now?

/test

/test-1.23-5.4

Just saw those in the test failures and corrected them haha. Should be good now?

Good from my perspective, thank you! Holding off on approving for now, as the verifier reject will presumably require additional changes :(.

/test

@michaelasp Instead of duplicating the current lookup helpers into one that checks for service backends and other doesn't, let's extend the helpers with a third parameter (check_svc_backends). Set the parameter to false for the bpf_lxc cases where the intention is to drop packets (make sure you keep the current L7 logic as-is). This way if you don't want to tackle socket-lb cases, the PR at least won't introduce new technical debt with almost similar named functions, and having duplicate code paths. As for introducing a new error code for the no backends case, it's okay if we keep things consistent with the rest of the code for now.

Sounds good, this makes it a lot cleaner. I think our main concern was editing the codepath at all for lb{4,6}_lookup_service. I don't think this adds any behavior that's different from before as long as check_svc_backends is set to true. Let me know what you think @aditighag and @julianwiedmann! I tested this again locally and it seems like it passes the verifier.

/test

@michaelasp note that the net-next CI run is calling out another complexity issue :/.
...
BPF program is too large. Processed 1000001 insn
processed 1000001 insns (limit 1000000) max_states_per_insn 32 total_states 69749 peak_states 2651 mark_read 70

libbpf: -- END LOG --
libbpf: failed to load program 'tail_handle_ipv4_from_netdev'
...
libbpf: failed to load object './test/bpf/../../bpf/bpf_host.o'
...
 Think I should switch back to the old method with separate helpers. It adds some tech debt but I think it'll pass the verifier. Or do you think there's a way to reduce the complexity keeping it in the same function?

Sigh, guess with the extra conditional it's too large in net-next. Think I should switch back to the old method with separate helpers? It adds some tech debt but I think it'll pass the verifier. Or do you think there's a way to reduce the complexity keeping it in the same function?

Just to be sure, can you check locally if the previous version passes the verifier on net-next?

Yep will do, don't think the net-next version had issues iirc, just 4.19.

Sigh, guess with the extra conditional it's too large in net-next. Think I should switch back to the old method with separate helpers? It adds some tech debt but I think it'll pass the verifier. Or do you think there's a way to reduce the complexity keeping it in the same function?

Can you try wrapping the checks with the unlikely macro. We've had instances of it appeasing the verifier in the past. In any case, service backends count being 0 is likely to be uncommon scenario anyway.

@aditighag Unfortuantely, seems to still fail the verifier. Think I should switch it back? Or is there something else I can try to get under the complexity limit?

Actually on further investigation I found out that it seems like the goto in lb{4,6}_local was causing some grief, seems to pass the verifier now. Looks like we can keep the refactored lb{4,6}_lookup_service and still have the verifier pass net-next. Haven't checked on other kernels yet since the test takes a while but hopefully it passes on them too.

/test

/test

Seems like the tests are running into failures, however I see the exact same thing here https://github.com/cilium/cilium/pull/21874 so don't think it's isolated to this change.

Seems like the tests are running into failures, however I see the exact same thing here #21874 so don't think it's isolated to this change.

Could you rebase on top of master? That should help with some of the failing test

Seems like the tests are running into failures, however I see the exact same thing here #21874 so don't think it's isolated to this change.

Could you rebase on top of master? That should help with some of the failing test

Done!

/test

/test-1.24-4.19

Thanks for your contribution @michaelasp :)

Think we want this for v1.12 as well. But there the verifier is acting up again (see https://github.com/cilium/cilium/pull/21943), so will backport manually.

I think this PR might have introduced #21979 on master.

For information: I am reverting this PR in #21981.

@julianwiedmann FYI I have removed the needs-backport label since this has been reverted on the master branch. We should follow up on the resubmission of this PR and set the label on that PR if it is still applicable.

For the record, this is the minimal config to reproduce the complexity issue:
diff --git a/bpf/complexity-tests/419/bpf_host.txt b/bpf/complexity-tests/419/bpf_host.txt
index 71a8cba21b..ea03035231 100644
--- a/bpf/complexity-tests/419/bpf_host.txt
+++ b/bpf/complexity-tests/419/bpf_host.txt
@@ -1,3 +1,4 @@
 -DSKIP_DEBUG=1 -DENABLE_IPV4=1 -DENABLE_IPV6=1 -DENABLE_SOCKET_LB_TCP=1 -DENABLE_SOCKET_LB_UDP=1 -DENABLE_ROUTING=1 -DNO_REDIRECT=1 -DPOLICY_VERDICT_NOTIFY=1 -DALLOW_ICMP_FRAG_NEEDED=1 -DENABLE_IDENTITY_MARK=1 -DMONITOR_AGGREGATION=3 -DCT_REPORT_FLAGS=0x0002 -DENABLE_HOST_FIREWALL=1 -DENABLE_ICMP_RULE=1 -DENABLE_CUSTOM_CALLS=1 -DENABLE_SRV6=1 -DHAVE_LPM_TRIE_MAP_TYPE=1 -DHAVE_LRU_HASH_MAP_TYPE=1 -DENABLE_MASQUERADE=1 -DENABLE_SRC_RANGE_CHECK=1 -DENABLE_NODEPORT=1 -DENABLE_NODEPORT_ACCELERATION=1 -DENABLE_SESSION_AFFINITY=1 -DENABLE_DSR_ICMP_ERRORS=1 -DENABLE_DSR=1 -DENABLE_DSR_HYBRID=1 -DENABLE_IPV4_FRAGMENTS=1 -DENCAP_IFINDEX=1 -DTUNNEL_MODE=1
+-DSKIP_DEBUG=1 -DENABLE_IPV4=1 -DENABLE_IPV6=1 -DENABLE_SOCKET_LB_TCP=1 -DENABLE_SOCKET_LB_UDP=1 -DENABLE_ROUTING=1 -DNO_REDIRECT=1 -DPOLICY_VERDICT_NOTIFY=1 -DALLOW_ICMP_FRAG_NEEDED=1 -DENABLE_IDENTITY_MARK=1 -DMONITOR_AGGREGATION=3 -DCT_REPORT_FLAGS=0x00ff -DENABLE_HOST_FIREWALL=1 -DENABLE_ICMP_RULE=1 -DENABLE_CUSTOM_CALLS=1 -DENABLE_SRV6=1 -DHAVE_LPM_TRIE_MAP_TYPE=1 -DHAVE_LRU_HASH_MAP_TYPE=1 -DENABLE_MASQUERADE=1 -DENABLE_SRC_RANGE_CHECK=1 -DENABLE_NODEPORT=1 -DENABLE_NODEPORT_ACCELERATION=1 -DENABLE_SESSION_AFFINITY=1 -DENABLE_DSR_ICMP_ERRORS=1 -DENABLE_DSR=1 -DENABLE_DSR_HYBRID=1 -DENABLE_IPV4_FRAGMENTS=1 -DENCAP_IFINDEX=1 -DTUNNEL_MODE=1 -DDISABLE_LOOPBACK_LB=1
 -DSKIP_DEBUG=1 -DENABLE_IPV4=1 -DENABLE_SOCKET_LB_TCP=1 -DENABLE_SOCKET_LB_UDP=1 -DENABLE_ROUTING=1 -DNO_REDIRECT=1 -DPOLICY_VERDICT_NOTIFY=1 -DALLOW_ICMP_FRAG_NEEDED=1 -DENABLE_IDENTITY_MARK=1 -DMONITOR_AGGREGATION=3 -DCT_REPORT_FLAGS=0x0002 -DENABLE_HOST_FIREWALL=1 -DENABLE_ICMP_RULE=1 -DENABLE_CUSTOM_CALLS=1 -DENABLE_SRV6=1 -DHAVE_LPM_TRIE_MAP_TYPE=1 -DHAVE_LRU_HASH_MAP_TYPE=1 -DENABLE_MASQUERADE=1 -DENABLE_SRC_RANGE_CHECK=1 -DENABLE_NODEPORT=1 -DENABLE_NODEPORT_ACCELERATION=1 -DENABLE_SESSION_AFFINITY=1 -DENABLE_DSR_ICMP_ERRORS=1 -DENABLE_DSR=1 -DENABLE_DSR_HYBRID=1 -DENABLE_IPV4_FRAGMENTS=1 -DENCAP_IFINDEX=1 -DTUNNEL_MODE=1
 -DSKIP_DEBUG=1 -DENABLE_IPV6=1 -DENABLE_SOCKET_LB_TCP=1 -DENABLE_SOCKET_LB_UDP=1 -DENABLE_ROUTING=1 -DNO_REDIRECT=1 -DPOLICY_VERDICT_NOTIFY=1 -DALLOW_ICMP_FRAG_NEEDED=1 -DENABLE_IDENTITY_MARK=1 -DMONITOR_AGGREGATION=3 -DCT_REPORT_FLAGS=0x0002 -DENABLE_HOST_FIREWALL=1 -DENABLE_ICMP_RULE=1 -DENABLE_CUSTOM_CALLS=1 -DENABLE_SRV6=1 -DHAVE_LPM_TRIE_MAP_TYPE=1 -DHAVE_LRU_HASH_MAP_TYPE=1 -DENABLE_MASQUERADE=1 -DENABLE_SRC_RANGE_CHECK=1 -DENABLE_NODEPORT=1 -DENABLE_NODEPORT_ACCELERATION=1 -DENABLE_SESSION_AFFINITY=1 -DENABLE_DSR_ICMP_ERRORS=1 -DENABLE_DSR=1 -DENABLE_DSR_HYBRID=1 -DENABLE_IPV4_FRAGMENTS=1 -DENCAP_IFINDEX=1 -DTUNNEL_MODE=1

@michaelasp FYI - I freed up some complexity with PR https://github.com/cilium/cilium/pull/22342. Re-spin of this one is in https://github.com/cilium/cilium/pull/22388.

Awesome, thanks for the help with this @julianwiedmann! The bpf verifier is a finnicky thing 😢.


Mention conference(s) on docs website

I don't know if we want to do such a thing, but do we want to add community driven conferences to the docs website. Angular is doing something similar here https://angular.io/events

closed by #4830


README should include information on Disabling Two-Factor Auth for an account

It has a section on enabling two-factor authentication, but not on disabling it.
I had a number of issues when trying to implement disabling 2FA.

I'm sorry about the lack of clarification. What sorts of issues did you run into? Pull requests are most welcome!

The major one, as I figured out, was due in part to my own stupidity. We were using Pundit to check if the user had the two_factor_verified set to false before allowing the user to enable 2FA. We disabled it and then re-enabled it, and it broke, since we weren't setting two_factor_verified to false when disabling. Would be nice to know what we're supposed to set/unset when the user disables two-factor authentication.

Are there instructions on how to migrate from database_authenticatable to two_factor_authenticatable?


Ruby Concurrent Requests

Hello, we are unable to make more than 4 concurrent requests using the Ruby client. When more than 4 concurrent requests are made the client seems to lock up until the requests time out. We are currently in an effort to add more concurrency in the Google Cloud Pub/Sub Ruby library, and while this seems to be working well while making concurrent streaming API calls, we are seeing the grpc client lock up while concurrently calling non-streaming APIs under moderate load.
To illustrate, I have included a ruby script that attempts to benchmark the performance differences between making sequential and concurrent requests. The default number of requests is 4, but you can pass in an argument to change the number of requests. This script will lock up and eventually time out when passing in a number larger than 4. Here is the output when running 4 and 6 concurrent requests:
$ ruby benchmark_gapic.rb 4
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007faed3afb160>
#<Google::Pubsub::V1::PublishResponse:0x007faed3ad8660>
#<Google::Pubsub::V1::PublishResponse:0x007faed3aa9bd0>
#<Google::Pubsub::V1::PublishResponse:0x007faed3a7b118>
  0.390000   0.500000   0.890000 ( 16.913990)
concurrent#<Google::Pubsub::V1::PublishResponse:0x007faed1845b20>
#<Google::Pubsub::V1::PublishResponse:0x007faed18a7898>
#<Google::Pubsub::V1::PublishResponse:0x007faed19372b8>
#<Google::Pubsub::V1::PublishResponse:0x007faed1955178>
  0.390000   0.540000   0.930000 ( 11.678385)

$ ruby benchmark_gapic.rb 6
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007ffd71951f48>
#<Google::Pubsub::V1::PublishResponse:0x007ffd71923418>
#<Google::Pubsub::V1::PublishResponse:0x007ffd719009b8>
#<Google::Pubsub::V1::PublishResponse:0x007ffd718d1f28>
#<Google::Pubsub::V1::PublishResponse:0x007ffd6f847488>
#<Google::Pubsub::V1::PublishResponse:0x007ffd6f8979d8>
  0.570000   0.700000   1.270000 ( 18.899312)
concurrent/Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:357:in `rescue in block (2 levels) in retryable': GaxError Retry total timeout exceeded with exception, caused by 4:Deadline Exceeded (Google::Gax::RetryError)
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:343:in `block (2 levels) in retryable'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:342:in `loop'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:342:in `block in retryable'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:262:in `block in catch_errors'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:224:in `block in create_api_call'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:250:in `block in create_api_call'
	from /Users/blowmage/google/codez/gcloud-ruby/google-cloud-pubsub/lib/google/cloud/pubsub/v1/publisher_client.rb:326:in `publish'
	from benchmark_gapic.rb:56:in `block (4 levels) in <main>'

Here is the script:
$stdout.sync = true
Thread.abort_on_exception = true

require "google/cloud/pubsub/v1"
require "grpc"
require "googleauth"
require "securerandom"
require "benchmark"

# This will benchmark publishing 1 million 4KB messages
# using the previous batch method, and the new async publisher

project = ENV["GOOGLE_CLOUD_PROJECT"] || "<ENTER-PROJECT-ID-HERE>"
keyfile = ENV["GOOGLE_CLOUD_KEYFILE"] || "<ENTER-KEYFILE-PATH-HERE>"

host = Google::Cloud::Pubsub::V1::PublisherClient::SERVICE_ADDRESS
chan_args = { "grpc.max_send_message_length"    => -1,
              "grpc.max_receive_message_length" => -1 }
auth = Google::Auth::ServiceAccountCredentials.make_creds \
  json_key_io: File.open(keyfile, mode: "r"),
  scope: Google::Cloud::Pubsub::V1::PublisherClient::ALL_SCOPES
chan_creds = GRPC::Core::ChannelCredentials.new.compose \
  GRPC::Core::CallCredentials.new(auth.updater_proc)
channel = GRPC::Core::Channel.new host, chan_args, chan_creds
pub_client = Google::Cloud::Pubsub::V1::PublisherClient.new channel: channel

topic_name = "loadtest"
topic_path = Google::Cloud::Pubsub::V1::PublisherClient.topic_path project, topic_name
topic_grpc = begin
               pub_client.get_topic topic_path
             rescue Google::Gax::GaxError => e
               raise e unless e.cause.code == 5
               pub_client.create_topic topic_path
             end

msg_data = SecureRandom.random_bytes 4*1024
messages = 1000.times.map { Google::Pubsub::V1::PubsubMessage.new data: msg_data }

n = (ARGV.first || 4).to_i

Benchmark.bm do |bm|
  bm.report "sequential" do
    # runs the publish requests synchronously
    responses = n.times.map do
      pub_response = pub_client.publish topic_path, messages
      puts pub_response # uncomment to see when recieved
      pub_response
    end
    # puts responses.inspect
  end

  bm.report "concurrent" do
    # runs the publish requests asynchronously
    threads = n.times.map do
      Thread.new do
        pub_response = pub_client.publish topic_path, messages
        puts pub_response # uncomment to see when recieved
        pub_response
      end
    end
    responses = threads.map &:value
    # puts responses.inspect
  end
end

This script is using the GAPIC layer to make the GRPC calls. I can rewrite it to make the calls on the GRPC stub directly, but the GAPIC layer doesn't look to be doing anything to prevent concurrent calls.

For whatever reason, the streaming APIs don't seem to have this issue. We can open 16 streaming connections and push/pull from them concurrently with no problem.

It looks like this is an issue with the GAPIC layer after all. I rewrote the script to make the calls directly on the GRPC stub and was able to make more than 4 requests concurrently:
$ ruby benchmark_grpc.rb 4
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007ff0818f8530>
#<Google::Pubsub::V1::PublishResponse:0x007ff0818c9dc0>
#<Google::Pubsub::V1::PublishResponse:0x007ff08189b6f0>
#<Google::Pubsub::V1::PublishResponse:0x007ff081879050>
  0.340000   0.290000   0.630000 ( 12.599871)
concurrent#<Google::Pubsub::V1::PublishResponse:0x007ff07f844aa0>
#<Google::Pubsub::V1::PublishResponse:0x007ff07f8a48b0>
#<Google::Pubsub::V1::PublishResponse:0x007ff080052328>
#<Google::Pubsub::V1::PublishResponse:0x007ff080070210>
  0.390000   0.520000   0.910000 ( 11.779743)
$ ruby benchmark_grpc.rb 6
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007fb64a8c8888>
#<Google::Pubsub::V1::PublishResponse:0x007fb64a89a0f0>
#<Google::Pubsub::V1::PublishResponse:0x007fb64a86ba20>
#<Google::Pubsub::V1::PublishResponse:0x007fb64a849380>
#<Google::Pubsub::V1::PublishResponse:0x007fb648046c98>
#<Google::Pubsub::V1::PublishResponse:0x007fb648096720>
  0.580000   0.700000   1.280000 ( 18.323580)
concurrent#<Google::Pubsub::V1::PublishResponse:0x007fb64803f290>
#<Google::Pubsub::V1::PublishResponse:0x007fb6480cfa48>
#<Google::Pubsub::V1::PublishResponse:0x007fb6490422f0>
#<Google::Pubsub::V1::PublishResponse:0x007fb6490601d8>
#<Google::Pubsub::V1::PublishResponse:0x007fb649092070>
#<Google::Pubsub::V1::PublishResponse:0x007fb6490c3f08>
  0.650000   0.900000   1.550000 ( 17.147526)
$ ruby benchmark_grpc.rb 8
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007f80ec9e0178>
#<Google::Pubsub::V1::PublishResponse:0x007f80ec9b1a08>
#<Google::Pubsub::V1::PublishResponse:0x007f80ec983310>
#<Google::Pubsub::V1::PublishResponse:0x007f80ec960c98>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb0465c8>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb094ef8>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb1372e8>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb154c58>
  0.770000   0.940000   1.710000 ( 24.771185)
concurrent#<Google::Pubsub::V1::PublishResponse:0x007f80eb03dab8>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb0bc408>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb15c430>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb19e2b8>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb1bc1a0>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb1ee038>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb21fed0>
#<Google::Pubsub::V1::PublishResponse:0x007f80eb23ddb8>
  0.850000   1.230000   2.080000 ( 22.813085)
$ ruby benchmark_grpc.rb 16
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007ffc809e1158>
#<Google::Pubsub::V1::PublishResponse:0x007ffc809b29c0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc80990348>
#<Google::Pubsub::V1::PublishResponse:0x007ffc80961c50>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f047580>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f084fc0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f1242f0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f155c10>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f187530>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f1a4ea0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f1d67c0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f02f868>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f08cc98>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f16d2c0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f1cf538>
#<Google::Pubsub::V1::PublishResponse:0x007ffc7f205778>
  1.500000   1.820000   3.320000 ( 50.884646)
concurrent#<Google::Pubsub::V1::PublishResponse:0x007ffc82dd3340>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82dc00d8>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82da9018>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d92b38>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d801b8>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d697d8>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d4b1e8>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d389f8>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d23198>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82d01c50>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82ceb568>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82cd8508>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82cc0d90>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82cab2d8>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82c917c0>
#<Google::Pubsub::V1::PublishResponse:0x007ffc82c7b128>
  1.900000   3.490000   5.390000 ( 45.391527)

Here is the updated script. It still creates the GAPIC client, but uses the GRPC stub from the client instead.
$stdout.sync = true
Thread.abort_on_exception = true

require "google/cloud/pubsub/v1"
require "grpc"
require "googleauth"
require "securerandom"
require "benchmark"

# This will benchmark publishing 1 million 4KB messages
# using the previous batch method, and the new async publisher

project = ENV["GOOGLE_CLOUD_PROJECT"] || "<ENTER-PROJECT-ID-HERE>"
keyfile = ENV["GOOGLE_CLOUD_KEYFILE"] || "<ENTER-KEYFILE-PATH-HERE>"

host = Google::Cloud::Pubsub::V1::PublisherClient::SERVICE_ADDRESS
chan_args = { "grpc.max_send_message_length"    => -1,
              "grpc.max_receive_message_length" => -1 }
auth = Google::Auth::ServiceAccountCredentials.make_creds \
  json_key_io: File.open(keyfile, mode: "r"),
  scope: Google::Cloud::Pubsub::V1::PublisherClient::ALL_SCOPES
chan_creds = GRPC::Core::ChannelCredentials.new.compose \
  GRPC::Core::CallCredentials.new(auth.updater_proc)
channel = GRPC::Core::Channel.new host, chan_args, chan_creds
pub_client = Google::Cloud::Pubsub::V1::PublisherClient.new channel: channel
pub_stub = pub_client.publisher_stub

topic_name = "loadtest"
topic_path = Google::Cloud::Pubsub::V1::PublisherClient.topic_path project, topic_name
topic_grpc = begin
               pub_client.get_topic topic_path
             rescue Google::Gax::GaxError => e
               raise e unless e.cause.code == 5
               pub_client.create_topic topic_path
             end

msg_data = SecureRandom.random_bytes 4*1024
messages = 1000.times.map { Google::Pubsub::V1::PubsubMessage.new data: msg_data }
pub_request = Google::Pubsub::V1::PublishRequest.new topic: topic_path, messages: messages

n = (ARGV.first || 4).to_i

Benchmark.bm do |bm|
  bm.report "sequential" do
    # runs the publish requests synchronously
    responses = n.times.map do
      pub_response = pub_stub.publish pub_request
      puts pub_response # uncomment to see when recieved
      pub_response
    end
    # puts responses.inspect
  end

  bm.report "concurrent" do
    # runs the publish requests asynchronously
    threads = n.times.map do
      Thread.new do
        pub_response = pub_stub.publish pub_request
        puts pub_response # uncomment to see when recieved
        pub_response
      end
    end
    responses = threads.map &:value
    # puts responses.inspect
  end
end

Apologies for not verifying this before opening this issue.


Two step device code flow

Hi Team, is there a plan to add a two step device code flow? In step-1, we get the device code and in the step-2, we get the token using the device code received from the step-1, this way, the device code flow can be used in a more complicated scenarios where performing both the steps/tasks at once is not doable/desirable.

Hi @neerajwadhwa-lcci, there is no plan to expose the two different steps device code flow. What are the scenarios where having MSAL perform both steps is undesirable?

Hi @sangonzal, because of security constraints, we can't perform ROPC on the server (this server is not built by us, pretty limited in terms of options available for OAuth). We have a method/functionality on the server that can be used to display the device code on the web portal so that the user can perform device code flow and we get the token but this doesn't work with default functionality provided by the MSAL lib, the device code can only be shown to the end user when this method/functionality to display something dynamic on the web portal is completely executed which means I won't be able to get the token by using that device code as there's nothing left to execute (this is a restriction from the server and the flow that it allows).

Closing, feel free to reopen in case of any follow up questions.


SL-396 release scripts

Jira: https://stoplightio.atlassian.net/browse/SL-396

Can this be closed?


RuntimeError: checkpoint url or path is invalid

(base) ubuntu@ip-172-31-34-181:~/Ask-Anything/video_chat_with_MOSS$ python app.py
/home/ubuntu/miniconda3/lib/python3.10/site-packages/torchvision/io/image.py:13: UserWarning: Failed to load image Python extension: 'libc10_cuda.so: cannot open shared object file: No such file or directory'If you don't plan on using image functionality from torchvision.io, you can ignore this warning. Otherwise, there might be something wrong with your environment. Did you have libjpeg or libpng installed before building torchvision from source?
warn(
Traceback (most recent call last):
File "/home/ubuntu/Ask-Anything/video_chat_with_MOSS/app.py", line 21, in
model = tag2text_caption(pretrained="pretrained_models/tag2text_swin_14m.pth", image_size=image_size, vit='swin_b' )
File "/home/ubuntu/Ask-Anything/video_chat_with_MOSS/models/tag2text.py", line 225, in tag2text_caption
model,msg = load_checkpoint_swinbase(model,pretrained,kwargs)
File "/home/ubuntu/Ask-Anything/video_chat_with_MOSS/models/tag2text.py", line 412, in load_checkpoint_swinbase
raise RuntimeError('checkpoint url or path is invalid')
RuntimeError: checkpoint url or path is invalid
Facing this issue, not able to fix this

you should download tag2text_swin_14m.pth and put it in pretrained_models/
wget https://huggingface.co/spaces/xinyu1205/Tag2Text/resolve/main/tag2text_swin_14m.pth ./pretrained_models/tag2text_swin_14m.pth


Add support for device overrides when creating/launching instance

Suggested at https://discuss.linuxcontainers.org/t/how-to-make-ips-fixed-to-an-instance-from-the-managed-bridge/14838/4?u=tomp
Proposal to add --device and -d flags to lxc launch and lxc init that would allow device override at create time.
Similar to what we have now for lxc copy and lxc move.
The format of the flag value would be the same, i.e -d <device_name>,<key>=<value>.

@stgraber @tomponline if overriding a single key from a profile (e.g. lxc launch images:alpine/edge c1 -d root,pool=remote) we don't know which profile contains the device that is having it's config key overridden, but we also cannot provide an incomplete device configuration on the instance.
We can either:

Query LXD for each profile until we have a matching device name and then fully populate the device config by combining the profile and the overridden key(s).
Force users to always specify a full device configuration, e.g. lxc launch images:alpine/edge c1 -d root,type=disk -d root,path=/ -d root,pool=remote.

I don't mind either way but for option 2 I wonder if there is a better syntax we can use, e.g. -d root:[type=disk path=/ pool=remote] (or something along those lines).

What is the current behavior for lxc copy, as we want it to mirror that.

You'd just pick the ExpandedDevices struct, copy the device from there and override the one key they provided.

Yeah I suspect thats what the current behaviour is.

So this is effectively the same as doing lxc init ... followed by lxc config device override ...


fix: copy README.md after building during release.yml

Not creating a new release this time so we don't keep releasing unnecessary extra versions. Should go out with next release.

Codecov Report

Merging #124 (2b4d807) into main (cb74bab) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #124   +/-   ##
=======================================
  Coverage   84.57%   84.57%
=======================================
  Files           9        9
  Lines         188      188
  Branches       44       44
=======================================
  Hits          159      159
  Misses         19       19
  Partials       10       10

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@Gabrola you should be able to merge now right? :D

@Gabrola you should be able to merge now right? :D

Yes 🎉


Add autoreset, info command and minor fixes to flasher

Adds a new command flash info which will return if the attached Blit is running firmware or game
Sets up the serial port with a timeout, so it wont block forever in case of weirdness
Auto resets from game to firmware if necessary for flashing (should fix #5)
Slightly improved wrangling the "directory" argument so it doesn't have three different default values depending on the wind direction

Reset causes the port to close, will need to handle that somehow.
Prepared for the build cleanup: https://github.com/Daft-Freak/32blit-beta/commit/9c8807e943741e52d140b1f0491b310472513c6b :)

That's odd- seems to reset fast enough to keep the port open for me and just flashes away. Must be a Windows-being-unusually-tolerant-for-a-change bug. I'll have to wrangle a reconnect in there somehow.


Write a Scala program to convert weeks to hours

Description
Write a Scala program to convert weeks to hours
1 week = 7 days = 168 hours
Input  : 5
Output : 840

How to contribute

Save the solution in convertWeeksToHours.scala file
Add convertWeeksToHours.scala file in convert-weeks-to-hours folder

!assign

Hey @TechnicalAmanjeet,
This issue has been assigned to you for more than 15 days.
We are unassigning you from this issue.
If you are still interested in contributing to this issue, please get auto-assigned on the issue by commenting !assign again.
Thanks for your contributions :)

!assign


Integration tests run when exclude argument is passed into the coverage check

The *_integration_test.py files should not be running in Pytest and Coverage check. There could be a bug in our checks that makes them run when the exclude argument is passed.

I don't know that there's anything we need to do here, this is just a consequence of how default args work: since we went from using a default arg with a non-empty value to providing that arg explicitly, we won't get the default anymore.
If this is something we think should work differently, then the general coverage_.py file could be updated to add *_integration_test.py to whatever other values were passed in, but that would honestly be a lot of complication (particularly due to the fact that the type of the argument is either a string or a sequence of strings, so there's extra heterogeneity to deal with).

^^ Good point. Closing.


chore: Fix grammar issue in migration message

Fixes the warning message displayed when you are about to create a migration with a warning.
Changes "Are you sure you want create this migration?" to "Are you sure you want to create this migration?"

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

Thank you!


Added a dummy promise that returns true for android API initialization

✏ Description
Fixes #167
This makes it match the iOS signature and fulfills what typescript says will be there.
This does not actually handle any errors so that should probably be added at some point in the future. This is mostly just to unblock ourselves as we are implementing the SDK. If someone wants to point me into the right direction for errors that I should be checking for then I am happy to do so. I see this as a small step in the right direction to prevent valid typescript applications from crashing unexpectedly.

@Ayyanchira do you know why the tests are failing? When I looked through the logs it seems that the tests are failing on iOS stuff which I haven't touched.

@keeslinp Thanks for the PR! For the tests, that was something on our side (we ended up switching to a slightly older version of RN in the integration test), which has since been merged into master. Feel free to pull in the latest, but we're okay with merging in this PR

@keeslinp Thanks for the PR! For the tests, that was something on our side (we ended up switching to a slightly older version of RN in the integration test), which has since been merged into master. Feel free to pull in the latest, but we're okay with merging in this PR

Who merges? I don't have access so if someone who has write access could do that, that would be super helpful.

@keeslinp Thanks for the PR! For the tests, that was something on our side (we ended up switching to a slightly older version of RN in the integration test), which has since been merged into master. Feel free to pull in the latest, but we're okay with merging in this PR

Who merges? I don't have access so if someone who has write access could do that, that would be super helpful.

I'll do it right now!


fixed URLs and fixed ray download error

Why are these changes needed?

fixed image and colab urls to point to main repo
fixed model download error in pdf2parquet in ray version

Related issue number (if any).

@sujee I tested this today. The local versions of both Python and Ray ran successfully. The Python version on Colab is fine, but the Ray version on Colab has the following problem:
Coming out of the pdf2parquet in Step 3.2 and inspecting the output in Step 3.3, I can only see mars.pdf and earth.pdf is missing! Does it mean that earth.pdf was not converted to pq? Please look into this.

@sujee Thanks for your help in debugging the problem! If I click on "Open with Colab" from the notebook in the repo, it takes the old version of the the notebook from the dev branch. In order to test the new version, so I had to open Sujee's fork directly from the Colab  [https://colab.research.google.com/github/sujee/data-prep-kit/blob/intro-example2/examples/notebooks/intro/dpk_intro_1_ray.ipynb] and then I was able to run the Ray version in Colab successfully.


Starter (tutorial?)

This starter, if it is meant to be a brief tutorial, seems incomplete? The instructions walk you through adding a stateless function Hello (Hello.tsx, index.tsx) but then doesn't use it. I understand that it then goes on to explain stateful  components, but the ignorant and unsuspecting user (me), is left with a  project that won't run.
(21,10): 'getExclamationMarks' is declared but its value is never read.
This is indeed true. The starter tutorial never then demonstrates how to use getExclamationMarks.

Typo on my end :)


MAINT: Filter unrelated warning

Quick fix for an unrelated matplotlib<->pyparsing warning that's showing up in CircleCI. Since we treat warnings as errors, CircleCI is currently failing (e.g., here for #11012).

I plan to merge this as soon as the CIs come back green so that master is back to green, but if anyone has comments I'm happy to make a follow-up PR


Dual LiveReload Refresh for 2.RC0 + SASS project

From @MathieuNls on October 10, 2016 22:35
Using the 2.1.0 cli serving a ionic 2.rc0 project with SASS (ionic serve), I got two livereload induced refresh.
The first refresh is triggered when main.js is transpiled and the second one when the the sass file is compiled. One refresh at the end of the sass process would be enough. It's kind of bothering to have to wait for the second refresh to verify things.
In addition, the sass compilation is triggered even when no .sass file is changed.
Ionic server commands, enter:
  restart or r to restart the client app from the root
  goto or g and a url to have the app navigate to the given url
  consolelogs or c to enable/disable console log output
  serverlogs or s to enable/disable server log output
  quit or q to shutdown the server and exit

[18:26:19]  bundle dev update started ...
JS changed:   www/build/main.js
[18:26:28]  bundle dev update finished in 8.61 s  **// Refresh signal sent here**
[18:26:28]  sass started ...
[18:26:28]  sass finished in 6 ms  **// Another Refresh signal sent here**

Copied from original issue: driftyco/ionic-cli#1512

Hello @MathieuNls , thanks for opening an issue with us! Would you mind giving this a test with the latest release of our cli and app-scripts? You can see our blog here for update instructions.

I have this problem as well (running the latest ionic CLI and app scripts).
Here's a log of the output from the moment I run ionic serve to when I've made a code change (that is detected twice):
C:\testapp>ionic serve
Running 'serve:before' npm script before serve

ionic-hello-world@ watch C:\testapp
ionic-app-scripts watch

[19:57:26]  ionic-app-scripts 0.0.36
[19:57:26]  watch started ...
[19:57:26]  build dev started ...
[19:57:26]  clean started ...
[19:57:26]  clean finished in 1 ms
[19:57:26]  copy started ...
[19:57:26]  transpile started ...
[19:57:26]  lint started ...
[19:57:28]  lint finished in 1.85 s
[19:57:29]  transpile finished in 3.27 s
[19:57:29]  bundle started ...
[19:57:29]  copy finished in 3.37 s
[19:57:38]  bundle finished in 8.77 s
[19:57:38]  sass started ...
[19:57:40]  sass finished in 2.17 s
[19:57:40]  build dev finished in 14.22 s
[19:57:40]  watch ready in 14.32 s
Running live reload server: http://localhost:35729
Watching: www//*, !www/lib//, !www/**/.map
√ Running dev server:  http://localhost:8100
Ionic server commands, enter:
restart or r to restart the client app from the root
goto or g and a url to have the app navigate to the given url
consolelogs or c to enable/disable console log output
serverlogs or s to enable/disable server log output
quit or q to shutdown the server and exit
ionic $ [19:58:43]  copy started ...
[19:58:43]  transpile update started ...
[19:58:46]  transpile update finished in 3.49 s
[19:58:46]  bundle update started ...
[19:58:46]  copy finished in 3.50 s
JS changed:   C:\testapp\www\build\main.js
[19:58:55]  bundle update finished in 8.28 s
[19:58:55]  watch ready
[19:58:55]  transpile update started ...
[19:58:57]  transpile update finished in 2.59 s
[19:58:57]  bundle update started ...
JS changed:   C:\testapp\www\build\main.js
[19:59:15]  bundle update finished in 17.32 s
[19:59:15]  watch ready
Here's my Ionic info:
Your system information:
Cordova CLI: 6.3.1
Ionic Framework Version: 2.0.0-rc.1
Ionic CLI Version: 2.1.1
Ionic App Lib Version: 2.1.1
Ionic App Scripts Version: 0.0.36
OS:
Node Version: v6.7.0

Hello @perdjurner ! This should be fixed in the latest beta release of app-scripts. Would you mind giving it a try? You can install it with npm install -g @ionic/app-scripts@beta. Thanks!

I have been seeing the same issue.
Tried updating to app-scripts@beta, and I'm seeing the following when I run ionic serve (note second-to-last line):
Running 'serve:before' npm script before serve

> testapp@ watch C:\testapp
> ionic-app-scripts watch

[14:04:01]  ionic-app-scripts 0.0.37
[14:04:01]  watch started ...
[14:04:01]  build dev started ...
[14:04:01]  clean started ...
[14:04:01]  clean finished in 6 ms
[14:04:01]  copy started ...
[14:04:02]  transpile started ...
[14:04:06]  transpile finished in 4.98 s
[14:04:06]  webpack started ...
[14:04:07]  copy finished in 5.38 s
[14:04:13]  webpack finished in 6.76 s
[14:04:13]  sass started ...
[14:04:13]  build dev failed: [object Object]
[14:04:17]  sass finished in 4.16 s

At this point is just hangs and never launches a chrome tab.
This is with an existing project that has been updated to RC1 from previous versions. It was working with<EMAIL_ADDRESS>or so (might have been .34 or .36, I can't remember exactly), aside from the double transpile/bundle update steps of course :smile:
Ionic info:
Your system information:

You have been opted out of telemetry. To change this, run: cordova telemetry on.
6.3.1

Gulp version:  CLI version 3.9.1
Gulp local:
Ionic Framework Version: 2.0.0-rc.1
Ionic CLI Version: 2.1.1
Ionic App Lib Version: 2.1.1
Ionic App Scripts Version: 0.0.37
OS: Windows 7 SP1
Node Version: v4.6.0

With 0.0.37 it gets to the "Build dev finished in..." step but then nothing happens (no browser opens).

Hello @perdjurner, sorry for the delay on this one! Can you make sure that you have all the files here including the manifest.json and the service worker? There is a bug with app-scripts at the moment that we are working on that makes the build halt when the copy task does not find a file.

Thanks, that fixed it.
There is still some double action going on though, see log below.
This is with App Scripts 0.0.37-2 and Ionic CLI 2.1.4.
[09:03:02]  build update started ...
[09:03:02]  transpile update started ...
[09:03:02]  transpile update finished in 71 ms
[09:03:02]  webpack update started ...
[09:03:02]  build update started ...
[09:03:02]  transpile update started ...
[09:03:02]  transpile update finished in 56 ms
[09:03:02]  webpack update started ...
JS changed:   C:\testapp\www\build\main.js
[09:03:07]  webpack update finished in 5.20 s
[09:03:07]  webpack update finished in 5.14 s
[09:03:07]  build update finished in 5.27 s
[09:03:07]  build update finished in 5.20 s
[09:03:07]  watch ready
[09:03:07]  watch ready

I have the same behaviour as @perdjurner .

Hi,
It appears to be fixed in 0.0.38.
I have only one reload.
Thanks !

Not fixed for me. I'm on 0.0.41 and it reloads twice or maybe even three times.
Same happens in a newly created ionic 2 app without any changes

It seems like this is fixed so I'm going to close this issue.
Thanks,
Dan


[Feature Request] Streaming SQL Joins / Continuous Queries

A new generation of server-side SQL engines are spawning a new kind of construct, Streaming SQL Joins:

Kafka's kSQL has the EMIT CHANGES keyword
Spark has stream-stream JOINs
Flink's default behavior ('time-varying relations') is to emit the changes
Materialize's value proposition is centered around event-streaming, and has Live Materialized Views.

Feature description:
While doing: SELECT * FROM orders o JOIN item i ON o.order_item_id = i.item_id, we would be able to listen to the changes from either side of the join; Without having to use TRIGGERs on both sides and re-emitting a query.
Changes would only stream the updated rows, insertions and deletions.
It would work on aggregations as well, sending the updated rows with the new aggregated values.

Advantages / use cases:

If you're doing event-streaming server-side and sending slices of a table to the client, you could have the same abstraction client-side, in the same language.
Moving business logic from client-side to server-side and vice-versa would be easier, as it would be expressed in the same language
SQL rules, SQL everywhere!
Reactive apps are easier b/c of cache management (there is none if you go full reactive).

This would be an ungodly amount of work, but I think AlaSQL is uniquely positioned to serve this use case, being the leader with sql.js in client-side SQL.
Out of curiosity: Is it something that could go on the long term roadmap?

Interesting.
What format are you thinking regarding the output for an event?

I'm not AlaSQL user yet and use currently RxDB and former WatermelonDB user. Both are great on reactivity. RxDB uses ATM rxjs. But lack of joins makes many parts a little bit ugly to work with.
For AlaSQL I can imagine following example:
const orders$: Observable<{
  id: number,
  user: string,
  name: string
}> = alasql.observe("SELECT o.id, o.user, i.name FROM orders o JOIN item i ON o.order_item_id = i.item_id")

orders$.subscribe(orders => console.log(orders))

If relevant data (~ filtered by where) is inserted, modified or deleted then the observer is fired.
What do you think @mathiasrw ? Is there any way to achieve that already?


Support  ingress-nginx Canary ?

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary

Yes, this is a useful annotation. At present, we support it by means of plug-ins. You can refer to the custom canary plug-in on the route or service through CRD (ApisixRoute & ApisixService).
The definition of annotation will be provided as a feature in the future, because we will rely on APISIX official canary plug-in support( @membphis ), and then we will provide both annotation and plugin ways .

Good news, the Apache APISIX community is discussing implementing a traffic-split plug-in, based on which canary can be implemented.
The discuss mail list is https://lists.apache.org/thread.html/rf02dc53a4af5d98d2513d89256b47466934d129af06d0bdcdb49cc8e%40<dev.apisix.apache.org>

As traffic-split has been merged in https://github.com/apache/apisix/pull/2935, we can support Canary now.
You can bind plugin in ApisixRoute or ApisixService to implement it.

As traffic-split has been merged in https://github.com/apache/apisix/pull/2935, we can support Canary now.
You can bind plugin in ApisixRoute or ApisixService to implement it.


Upgrade to Symfony 6.x

Steps required to reproduce the problem

try to upgrade to symfony 6.0

Expected Result

compatibility to symfony 6.0

Actual Result

depending on symfony 5.4

Hey guys. First thanks for the great package and the work you have done. i am facing a problem right now, that the bundle is depending on a lot of symfony 5.4. packages. even if 5.4.* is LTS up to nov. 2024 i tried to upgrade to 6.0.
do you plan an upgrade to 6.x soon or later?
cheers
Andi

Version 1.x will not be updated to support Symfony 6.
The 2.x branch already supports it, there is no released version 2.0 yet.
This will come by the end of the year.

hey dragos,
thanks a lot for the quick reply. i will wait for Version 2.x


Memory leak caused by @validate_call decorator

Discussed in https://github.com/pydantic/pydantic/discussions/7912

Originally posted by ff137 October 24, 2023
Edit: found related issue #7687
Original problem is described in above discussion. The cause of the memory leak was isolated to originating from the @validate_call decorator.
Here's a basic script to reproduce the memory leak issue:
import asyncio
import tracemalloc
from typing import Any, Dict, List, Optional, Tuple, Union
from uuid import uuid4

from aries_cloudcontroller import (
    AcaPyClient,
    CreateWalletRequest,
    CreateWalletResponse,
    MultitenancyApi,
)
from pydantic import BaseModel, Field, StrictFloat, StrictInt, StrictStr, validate_call
from typing_extensions import Annotated

# Our custom request model
class CreateTenantRequest(BaseModel):
    wallet_label: str
    wallet_name: Optional[str] = None
    roles: Optional[List[str]] = None
    group_id: Optional[str] = None
    image_url: Optional[str] = None

# stub the MultitenancyApi module that is called in cloudcontroller, with identical method signature
class StubbedMultitenancyApi(MultitenancyApi):
    @validate_call  # memory leak disappears if this is commented out
    async def create_wallet(
        self,
        body: Optional[CreateWalletRequest] = None,
        _request_timeout: Union[
            None,
            Annotated[StrictFloat, Field(gt=0)],
            Tuple[
                Annotated[StrictFloat, Field(gt=0)], Annotated[StrictFloat, Field(gt=0)]
            ],
        ] = None,
        _request_auth: Optional[Dict[StrictStr, Any]] = None,
        _content_type: Optional[StrictStr] = None,
        _headers: Optional[Dict[StrictStr, Any]] = None,
        _host_index: Annotated[StrictInt, Field(ge=0, le=0)] = 0,
    ) -> CreateWalletResponse:
        pass

# patch the AcaPyClient to use the stubbed MultitenancyApi
class PatchedAcaPyClient(AcaPyClient):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        # Replace the standard MultitenancyApi with our patched version
        self.multitenancy = StubbedMultitenancyApi(self.api_client)

# Use patched client to call `create_wallet`
async def simulate_cloudcontroller_api_call(data):
    wallet_request = CreateWalletRequest(**data)  # convert our custom request model to cloudcontroller model
    async with PatchedAcaPyClient("nohostneeded", admin_insecure=True) as client:
        await client.multitenancy.create_wallet(wallet_request)

async def create_tenant(data):
    tenant_request = CreateTenantRequest(**data)  # populate our custom request model
    wallet_data = {
        "image_url": tenant_request.image_url,
        "key_management_mode": "managed",
        "label": tenant_request.wallet_label,
        "wallet_key": "some_random_key",
        "wallet_name": tenant_request.wallet_name or uuid4().hex,
        "wallet_type": "askar",
    }
    await simulate_cloudcontroller_api_call(wallet_data)

# call `create_tenant` n times and print memory stats
async def main():
    tracemalloc.start()

    n = 1000  # create n tenants

    # Dummy request data
    data = {
        "wallet_label": "wallet1",
        "roles": ["issuer"],
        "image_url": "http://example.com/image.png",
    }

    # Loop to simulate repeated calls
    for _ in range(n):
        await create_tenant(data)

    print(f"Memory usage after {n} tenants created:")
    snapshot = tracemalloc.take_snapshot()
    top_stats = snapshot.statistics("lineno")
    for stat in top_stats[:5]:
        print(stat)

asyncio.get_event_loop().run_until_complete(main())

After installing the cloudcontroller dependency (pip install aries-cloudcontroller), you can run the script (python script.py).
(Note: also install latest pydantic)
The above script stubs the original cloudcontroller API calls that would be made with the create_tenant request.
Memory stats are printed at the end of the script's runtime as follows:
Memory usage after 1000 tenants created:
../lib/python3.9/site-packages/pydantic/_internal/_core_utils.py:210: size=11.5 MiB, count=71673, average=168 B
../lib/python3.9/site-packages/pydantic/_internal/_core_utils.py:585: size=7473 KiB, count=105985, average=72 B
../lib/python3.9/site-packages/pydantic/_internal/_core_utils.py:353: size=1801 KiB, count=10988, average=168 B
../lib/python3.9/site-packages/pydantic/_internal/_generate_schema.py:689: size=1001 KiB, count=16014, average=64 B
../lib/python3.9/site-packages/aiohttp/client.py:317: size=984 KiB, count=1000, average=1008 B

As you can see, pydantic is holding on to memory. Each of those _core_utils.py code lines points to somewhere that .copy() or validation is called.
If you run the above script again, but this time commenting out the @validate_call decorator, you get:
Memory usage after 1000 tenants created:
../lib/python3.9/site-packages/pydantic/_internal/_core_utils.py:210: size=17.2 KiB, count=114, average=154 B
../lib/python3.9/site-packages/pydantic/_internal/_core_utils.py:585: size=4496 B, count=64, average=70 B
../lib/python3.9/site-packages/pydantic/_internal/_core_utils.py:353: size=4056 B, count=26, average=156 B
../lib/python3.9/site-packages/pydantic/_internal/_generate_schema.py:2009: size=1936 B, count=19, average=102 B
../lib/python3.9/site-packages/pydantic/_internal/_generate_schema.py:689: size=1848 B, count=24, average=77 B

Then there is no excessive holding on to memory!
Ultimately, it is coming down to model validation being called for each request (on a complex model), and for some reason this is not garbage collected. Adding manual gc.collect() calls in the override methods, or things like del body, does not solve it.
Fortunately, I think we can get away without using the @validate_call method, because our API already does model validation upon receiving requests, before forwarding it to the AcaPyClient, so the secondary validation is probably redundant.
But this of course unexpected behaviour. @samuelcolvin is this a known issue, with any possible workarounds? Or have we stumbled on something new?

@ff137 I was able to reproduce the issue using your script and after some investigation I have found a bug in pydantic-core that I believe is the source of your problem: https://github.com/pydantic/pydantic-core/pull/1100. With the version of pydantic-core from that PR, I get:
Memory usage after 10 tenants created:
pydantic/_internal/_core_utils.py:210: size=5040 B, count=42, average=120 B
pydantic/_internal/_core_utils.py:585: size=4008 B, count=59, average=68 B
pydantic/plugin/_schema_validator.py:49: size=2311 B, count=32, average=72 B
pydantic/_internal/_generate_schema.py:2017: size=1600 B, count=10, average=160 B
pydantic/_internal/_model_construction.py:537: size=1568 B, count=2, average=784 B

even with the @validate_call decorator on. (Without that change, it's more like ~8.5MB in that first line.)

@dmontagu epic!! Thank you for looking into this, and great job to fix it so quickly. Amazing that it's just a 1 line change 😄