Cop suggestion: Detect unnecessary usage of let!

I often come across code which uses let!(...) for setting up state, but then never makes any direct reference to those identifiers. This setup should be in a before block, or inlined into the example's it block:
Bad
let!(:my_widget) { create(:widget) }

it "..." do
  expect(Widget.count).to eq(1)
end

Good
before { create(:widget) }

it "..." do
  expect(Widget.count).to eq(1)
end

or
it "..." do
  create(:widget)
  expect(Widget.count).to eq(1)
end

👍

@andyw8 this is implemented in master

@andyw8, @jcoyne asked:

Why is this bad? Can you provide some justification? Is this just personal preference?

Care to weigh in? I'll be able to provide context later potentially but I'll let you respond since you originally proposed this cop

If this is a problem, why hasn't it be proposed for deprecation/removal in rspec itself?

@jcoyne we aren't flagging all violations. The cop detects when you use let! and don't reference the defined method. The cop is encouraging you to only use let! when you need to reference the value later and otherwise use before for setup

I guess I don't see what the harm/benefit of that is.  If anything the name is giving some context to the reader of the spec.

Before I defend the cop further I'll note that these cops are supposed to be opinionated. This is why many are configurable. You're always free to disable particular cases, disable cops for a directory, or disable them entirely.
Consider the following snippet of code
def write_user
  user = database.persist(user_info)

  do_some_work
  do_some_other_work

  true
end

I think this is similar to the argument you are making about an unreferenced let!. I'd say that this local variable assignment to user should be removed because it isn't being used in the rest of the method. If I wanted to add some context for that write then I'd add a comment above it.
Likewise, consider this spec:
let!(:user) { database.write_user(user_info) }

before do
  do_some_work
  do_some_other_work
end

it "asserts something" do
  expect(something_that_depends_on_db_state).to be(true)
end

I think it is odd to read over this spec, see the assignment to user using the let!, but not see any usage of user. Just like the other example I would instead just make the side effect happen in before and if I wanted to give context I would write a comment

We should at least disable this cop by default. Quite the opposite: let! should be generally preferred over before, because before can't be turned off in a nested context.

@dpisarewski can you give me an example of "disabling" a let! in a nested context?

@backus For example:
describe Product do
  subject { product }

  let!(:product) { create(:product) }

  it { is_expected.to be }

  context 'when product does not exist' do
    let!(:product) { nil }

    it { is_expected.to be_nil }
  end
end

Another reason I think this is a bad cop: If you create records and perform other setup in a before block, there's no description of the record. With a let! you can be desriptive:
let!(:nonmatching_user_in_same_organization) { FactoryBot.create(:user, organization: user.organization) }

In a before block, that isn't easy. It could be placed in a comment, but there's no standard for it and no cop that would be able to enforce it.

@dpisarewski I think let!
Overriding let! with nil value is a hack to avoid creating that. Also note that if you have more nested context or shared examples, included context then needs to check whether the referenced variable is nil or not, which indicates bad context structure.
If you need to "undo" let!, probably it would be better to rewrite with different context.
describe Product do
  subject { product }

  context 'when prooduct exists' do
    let!(:product) { create(:product) }
    it { is_expected.to be }
  end

  context 'when product does not exist' do
    it { is_expected.to be_nil }
  end
end

@RobinDaugherty For descriptive name - you may use just variable name with _ prefix. When it's not referenced, no need to use let! without referencing it.
describe Foo do
  context 'when .... ' do
    before do
      _nonmatching_user_in_same_organization = FactoryBot.create(:user, organization: user.organization)
    end
  end
end

What benefit is there to placing these in a before block instead of a let!?
The alternative of using a before blocks creates values that are also not referenced in the tests, and are in addition not lintable since they are either not assigned to a variable, or are assigned to an underscore-prefixed variable and are therefore ignored by the linter. This smells like a bad default rule. It removes contextual hints placed in code for little or no benefit.
To return to the original description of this PR:

This setup should be in a before block, or inlined into the example's it block

Placing setup in an it block is bad practice. It leads to non-described pieces of context, which is what let exists to fix. It makes it more difficult to add a second example with the same context, which leads to multiple assertions in the same example, which is generally also bad practice. (In other words, instead of adding another descriptive spec, it's less friction to add more business assertions to the same spec instead of extracting setup from the spec at the same time.)
The point of this comment thread is that this rule is not well though-out and wasn't discussed prior to implementation. The majority of reactions to this issue are downvotes. There was no discussion as to the relative benefits of the rule before it was merged in #162 and enabled by default. Multiple people have asked for that default to be changed. It seems like a bad default that will lead to worse practices, not better.

If you need to refer to a value across example groups, a let is great. Otherwise, why do you need a memoized helper method? I think the logic is almost the same as checking for an unused variable.
Imagine you had this code:
it 'does something' do
  current_user = User.create!(...)
  expect(Users.count).to be(1)
end

RuboCop (and ruby, actually) would flag current_user as an unused variable. Why is the lvar created if it's not going to be used? Remove the assignment and add a comment if you need to explain why it is there (or you can also underscore the variable).
What this cop is advocating is similar: If all you want to do is provide some sort of side effect for setup, that's what before is designed for.
If you have a test where you need to do let!(:user) { User.create!(...) } and then reference user, this cop won't complain. When I see let!, it makes me think that that named memoized helper method should be used somewhere. before communicates to me "hey, here's some setup that changes the state of the world and you should be aware of when evaluating the following examples".
As an aside, I think the many uses of let! are mistakes because they typically involve persisting database records that don't need to be persisted. Unit tests, ideally, should avoid as much I/O as possible and let! is a common trap for this.

The alternative of using a before blocks creates values that are also not referenced in the tests, and are in addition not lintable since they are either not assigned to a variable, or are assigned to an underscore-prefixed variable and are therefore ignored by the linter.

I think it's slightly easier to have errant let!s pile up in your code because it's harder to tell if someone meant to be doing a before and just performing some setup or if someone was originally referencing the let!'d value but have since removed the reference and the let! should be dead code but is executed anyway. I find it easier to audit setup in a before because I know it's clearly intended just to do some setup. With RuboCop and RSpec, a let is also not lintable since it does not tell you if a let is no longer referenced (shameless plug: I made a tool to monkey patch RSpec to do this: https://github.com/dgollahon/rspectre but it's not a perfect solution).

Placing setup in an it block is bad practice.

I'm going to have to disagree with this blanket rule. If the setup is only applicable to a single example, I usually prefer inlining it. It's actually more lintable and, imo, it's easier to understand in one glance since it's all in one place. let, before, etc. are all great when you need to deduplicate setup. If you only use the setup once or twice, my advice is to skip the features you don't need and lift things out as you need.
Your point about adding extra examples requiring an additional step is valid, but it's a tradeoff I'm frequently happy to take. I find I avoid more convoluted RSpec setup this way (I often have to modify let calls and test structure when I add more examples either way).
I don't have that strong of a feeling about this cop because I rarely use let!, but I think the logic behind it is consistent: if you don't use a name, don't bind a name.

The point of this comment thread is that this rule is not well though-out and wasn't discussed prior to implementation. The majority of reactions to this issue are downvotes. There was no discussion as to the relative benefits of the rule before it was merged in #162 and enabled by default. Multiple people have asked for that default to be changed. It seems like a bad default that will lead to worse practices, not better.

I don't think these arguments are accurate or constructive. I think you are assigning blame where none is due:

I think it was well thought out and based on a consistent principle.
A feature was proposed, agreed on, and implemented--downvotes came much later. Furthermore, there are only a few votes either way. 4 downvotes after more than 2 years is hardly a consensus.
It seems bad to blame the implementors for not having enough discussion when no one objected before it was merged. Adding features is better than waiting to see if dissenters show up.
I doubt this would lead to worse practices on average, but if you're right, then let's figure out how to improve the documentation and explain the "don't name this if you don't reference it" rationale better.

And, as with all cops, the user is free to disable it for themselves--RuboCop is supposed to be configurable.

Look, even the style guide disagrees with this rule.

Use let! to define variables even if they are not referenced in examples. This can be useful to populate your database to test negative cases.

I recommend you adopt better practices for deciding on changes to default rules, and these should probably include following the project's style guide and deliberating on a new rule before adopting it in the default ruleset.

Look, even the style guide disagrees with this rule.

I agree this should be made consistent. I think this advice should be removed from the style guide.
As an aside, I don't care for having a style guide just for the difficulty of keeping things like these in sync. Personally I think we should just generate something directly from the config, but that's another problem for another day.

I recommend you adopt better practices for deciding on changes to default rules, and these should probably include following the project's style guide and deliberating on a new rule before adopting it in the default ruleset.

I think the thought, going forward, for rubocop (and I assume rubocop-* projects) is to make all new cops opt-in until a major version is released when they become default but I can't remember all the details. Historically introducing a disabled cop didn't make much sense because no one would ever find it so people have just added and enabled all new cops and users can disable as they like. Defaults are changed pretty rarely outside of newly added cops.

@mikegee

You make strong arguments in support of this statement, but it's not black and white. The Arrange/Act/Assert style of unit testing advocates putting the setup in each unit test.
Sharing setup and context between tests may be a code smell. Perhaps the system under test needs a redesign to simplify its setup. Or, the setup could be extracted such that its just a method call in each test.

In the opposite, this pattern is about separation of Setup, Action and Assertion phases, not about putting everything together. The code on the page is just a trivial example without using any testing frameworks. Every testing framework defines a DSL/API to separate those, eg. SetUp()/TearDown() in JUnit, before/after in RSpec.
Can you please explain why sharing a setup is a code smell? This is the main purpose of nesting contexts IMO.

@dgollahon In Soviet Russia specifications refer to implementations. 😀
Well, I don't think any style guide should/could be autogenerated from a linter config. People use to agree on the document(style guide), not on linter code/config. There can be many linters with different preferences or configs, and ideally linters precisely follow the style guide. Furthermore, some rules may be unlintable at all.

I agree this should be made consistent. I think this advice should be removed from the style guide.

Why not remove the cop? I think, we should invert the cop, so let! should be preferred over before for reasons I mentioned above(no way to manage/disable before blocks programmatically) and also because the majority disagrees on this rule.
From my experience before blocks cause much more issues. before blocks also tend to grow with code changes, since they have no name which identifies their purpose. Developers just put everything they need for the setup in that damn before block. Then statements in it are executed for each example even when many examples need only some of the statements put into the before.
In general, I don't get why it hurts you to name a piece of code when the name is not used programmatically. In my opinion it greatly improves code readability and is preferred over comments in ruby community.

Just for your information, this cop was added two years ago, while the let! recommendation was added (copied directly from betterspecs) three weeks ago.
There was a bit of discussion in the style guide PR (https://github.com/rubocop-hq/rspec-style-guide/pull/55#discussion_r231796923) and I believe the intention is to change the style guide. See e.g. https://github.com/rubocop-hq/rspec-style-guide/issues/56 which references the RSpec maintainer’s comment on a Reddit AMA (https://www.reddit.com/r/ruby/comments/73nrhk/ama_the_authors_of_effective_testing_with_rspec_3/dnsyanp/):

I find before and let to be useful for particular situations, but find that they often get mis-used/abused in the wild, unfortunately. My rule of thumb is to use them when there's a compelling benefit, but don't reach for them as the default way to write specs.

@dpisarewski

@chulkilee Why would changing a value be a hack?

Don't get me wrong - I'm not against of overriding values with let or let! in nested context.
What I'm calling "a hack" is returning nil in let! only as a workaround to avoid instantiaing the value given by the original let!. It can be avoided by using separate context when let! value is needed - instead of placing the let! unnecessarily at the parent context.
Here is an example of doing that:
describe Product do
  let!(:product_image) { create(:product_image) } # <- is it really needed for all examples?

  describe '#images' do
    it 'returns an image' do
      # ...
    end

    context 'having no image' do
      let!(:product_image) { nil } # <-- I'd call it as a "hack"

      it 'does not return an image' do
        # ...
      end
    end
  end
end

This can be refactored like this - without overriding let! to return nil.
describe Product do
  describe '#images' do
    context 'having an image' do
      # now let! makes sesnses with the context
      let!(:product_image) { create(:product_image) }

      it 'returns an image' do
        # ...
      end
    end

    context 'having no image' do
      it 'does not return an image' do
        # ...
      end
    end
  end
end

There are many ways to group examples - for example if you have very large test cases for a setup, then it might be bettero to have separate rspec files, instead of placing all tests under one file - e.g. product_spec.rb and product_with_image_spec.rb. Playing with many level of context and figuring out what's overrided or where a variable is defined is very bad experience.
Also please note that youmay just use plain ruby helper module or factory bot trait to set up, instead of applying lots of let! in spec files.

For descriptive name - you may use just variable name with _ prefix. When it's not referenced, no need to use let! without referencing it.

@chulkilee It sounds like a big hack :scream:

A feature was proposed, agreed on, and implemented--downvotes came much later. Furthermore, there are only a few votes either way. 4 downvotes after more than 2 years is hardly a consensus.

@dgollahon  15 downvotes to be exact :wink:

so we're still discussing this, a few years after it first came up. I am on the fence of let|let! was implemented specifically to declare variables used (and reused) in specs. it wasn't originally (back in the day) inherent or descriptive about whether they must be used or not, it just said, let enables you to create a macro which will execute the code (like a proc) on call. let! will execute on definition.
yes these have been abused over time, but mostly by newer-to-the-profession engineers who are trying to figure it all out, and for rails apps for which every-guest is both a mystery and a first-class participant.
In actuality, over the past dozen or so years doing this, I can safely say that at least 70% of the apps i've worked on have always-enabled objects that form a basic part of the domain. Who can imagine a webapp that doesn't require some kind of user object?
So, we're forced to use mechanics like this to establish our orchestra before we begin the recital. Yes, we could use before blocks, but we're also encouraged to move towards smaller blocks of code that don't repeat-- something that using before doesn't really support (and has been mentioned above). Some have mentioned calling setup-methods that get your environment ready, but then of course you lean on centralizing these, and wait - that's what shared_context was sorta supposed to enable.
This cop doesn't have any true basis in best practice. I have not found any reasonable reference in the style guide. I know that original reasoning for creating the behavior was designed to set this up. So all I have left is to accept this is @andyw8's (or shopify's) personal preference, and not necessarily something that matches the entire community.
Strong advocate to making this disabled-by-default moving forward.

So all I have left is to accept this is @andyw8's (or shopify's) personal preference

My initial post was here from four years before I joined Shopify. Anything I post here is in a personal capacity and does not reflect any Shopify preference. (also, RSpec is not rarely used at Shopify anyway).

So all I have left is to accept this is @andyw8's (or shopify's) personal preference

My initial post was here from four years before I joined Shopify. Anything I post here is in a personal capacity and does not reflect any Shopify preference. (also, RSpec is not rarely used at Shopify anyway).

Ah, thanks for clarifying! I didn't know :D :D

Let me try to add an aspect to this discussion which wasn't mentioned yet: readability of tests.
Setups like the one mentioned by @chulkilee (let! used as a hack) can lead to huge problems in large test files. The reader of a single test cannot easily grasp the context anymore. before is easier to scan for and to reason about. In tests I prefer DAMP over DRY.
let and let! just look too similar. So I normally use let! in close vicinity to the test itself (it-block) and before further away.

As annoying as this check may be, this specific check/cop can be turned off by adding the following in your .rubocop.yml file:
RSpec/LetSetup:
  Enabled: false

before is easier to scan for and to reason about. In tests I prefer DAMP over DRY.

This hits the nail on the head. I wonder if RSpec has encouraged a little too much DRYing which have hence led to less readable tests?


Fix & fill translations

I fixed some translations that were not accurate or that were build incorrectly with an English or Spanish influence. I set them as the usual Catalan form.
I also added a couple of translations that were empty.

Please read the README.

@rogerpro: With a few tiny changes (such as treating the user with vós instead of tu, per Softcatalà’s guidelines), I’ve implemented your changes at https://crowdin.com/translate/poedit. Please go there next time ;)


How to reset component into initial status?

I am using this inside modal with Cancel and Save button.
It work well, but when user Cancel submission after he upload some image, I would like to init this component.
But it shows previous images. I tried with [uploadedFiles] with no success.
How can I solve this?

How to clear image preview after image upload without clicking on cross button

Hi,
you can reset the list of previewed images by referencing the component in code and calling deleteAll() function..
// reference the image uploader instance in code @ViewChild('imageInput') imageInput: ImageUploadComponent; this.imageInput.deleteAll();
// set the identifier in the markup <image-upload #imageInput"
Hope this helps!


authentication problem with 2.3.0 update from 2.2.7

After yum update and arango upgrade, I can't log in through the Web UI or the Arangosh and use my old databases with the old credentials.
restart of service does not fix it but:
If I disable the authentication, then using arangosh create new accounts or recrete the old ones,
I can login sucessfuly with any account but only once. After that one login, all subsequent authentications fail.
Another thing to note is that with authentication enabled, if I $arangosh (as root with empty password). when I try to >db._useDatabase("myOldDb"); I get ArangoError 401: Unauthorized.
Did not find anything helpful / out of the ordinary in any of the two logs ("/var/log/arangodb/arangod.log.daemon" or "/var/log/arangodb/arangod.log").
At the moment in order to work I have to disable the authentication (which isn't quite the workaround).
System Information:
CentOS 6.6
$arangod --version
architecture: 64bit
build-date: 2014-11-18 18:12:36
icu-version: 52.1
libev-version: 4.11
maintainer-mode: false
openssl-version: OpenSSL 1.0.0-fips 29 Mar 2010
server-version: 2.3.0
sizeof int: 4
sizeof void*: 8
v8-version: 3.16.14
*update: just tried creating a new db and new user for it. that works as it should.
**update2: after many service restarts and tests, I found an acceptable solution: if I create a new user with a different username than the old one, it works. Still, the old accounts behavior is erratic.
(keep it at least as a solution, in case other people find themselves in the same spot as me)

I'm currently experiencing the same or similar issue - after installing 3.0.4 on windows
Unfortunately this is my first time I'm actually trying to use arango so I don't know much of anything yet.
I may have installed a previous version - in fact I think I did but never got around to playing with it.

You should have provided the root password during the setup procedure, if you didn't, it should be empty. Since this ticket is way old, please leave it buried, and if your problem persists open a new one with a bit more detailed description what you did and trying to do and what failed.

Thanks - it seems that us the problem :
The installer does not apply the password I specified. Blank password works.
On Fri, 19 Aug 2016 at 10:41 AM Wilfried Goesgens<EMAIL_ADDRESS>wrote:

You should have provided the root password during the setup procedure, if
you didn't, it should be empty. Since this ticket is way old, please leave
it buried, and if your problem persists open a new one with a bit more
detailed description what you did and trying to do and what failed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arangodb/arangodb/issues/1116#issuecomment-240961934,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzkBcugmpqAjg3zXxPDP8Wb26X9hft3ks5qhWw4gaJpZM4C_zgA
.


zotero-beta: 7.0.0-83 -> 7.0.0-111

Description of changes
Update the beta version to 7.0.0-111

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Closes this issue https://github.com/NixOS/nixpkgs/issues/332023

Result of nixpkgs-review pr 332039 run on x86_64-linux 1

1 package built:

zotero_7 (zotero-beta)


Decline Transaction Changes

#680
Changed the transaction history message for Decline.
Changelog:

Fixed an issue with declining
Changed the transaction history message for Decline

 Credit Transactions | Adjust Transaction History entries for Credit Transactions - Credit Transfer Proposals & PVRs |3|


Update CharactersTest.java to fix test

Turned the monsters into monsters to pass the FindMonsters test.

I can't see how I missed this... thanks

You are welcome! Thanks for doing these. We worked through the Naming as a Process learning hour with two Python and one Java breakout group and it was great!


PLAT-4837 - Specify priorities for routing rules

Added priorities to the routing rules, which are no longer optional (see https://github.com/hashicorp/terraform-provider-azurerm/issues/16793 and https://github.com/hashicorp/terraform-provider-azurerm/pull/16794)

... We should allow some room for other rules just in case...

Great suggestion. 👍


Cyberark Audit service integration

Required items, please complete
Change(s):
Add new Data Connector for CyberArk Audit service.
Checked that the validations are passing and have addressed any issues that are present:
arm-ttk validation passed

@microsoft-github-policy-service agree

Hello @nitsan-tzur,
Just to confirm. You used V3 tool to package the solution?
Python libraries mentioned in requirements.txt doesnt have specific version. Please mention version as well.

Hello @nitsan-tzur, Just to confirm. You used V3 tool to package the solution?
Python libraries mentioned in requirements.txt doesnt have specific version. Please mention version as well.
Hi,
I did use the V3 tool. Added concrete versions to requirements.txt

Please create a custom table named as CyberArk_AuditEvents_CL at location .script/tests/KqlvalidationsTests/CustomTables

Please create a custom table named as CyberArk_AuditEvents_CL at location .script/tests/KqlvalidationsTests/CustomTables
Theres an extra folder for .python packages which includes python libraries mentioned in requirements.txt

done

Hello @nitsan-tzur, I've packaged the solution. Can you provide me credentials to test the content of the solution.
you can mail me them at<EMAIL_ADDRESS>

Hello @nitsan-tzur, I've packaged the solution. Can you provide me credentials to test the content of the solution. you can mail me them at<EMAIL_ADDRESS>
Sent details to specified email

Receieved

Hello @nitsan-tzur, Can you share working images of function app. I tried deploying it in 3 different workspaces and subscriptions but every time I'm facing an error reasons being location and Dynamic VM's

Hello @nitsan-tzur, Can you share working images of function app. I tried deploying it in 3 different workspaces and subscriptions but every time I'm facing an error reasons being location and Dynamic VM's

Hi, This deployment template settings worked for me:

Please note that the aka.ms URL seems to be wrong. It does not lead to the package

Hello @nitsan-tzur,
You attached a screenshot of deployment page which had credentials. Which may had lead to unwanted activities.
I have deleted the screenshot.
Can you share working screenshot of function app. ( Output/Result )

Hello @nitsan-tzur, You attached a screenshot of deployment page which had credentials. Which may had lead to unwanted activities. I have deleted the screenshot.
Can you share working screenshot of function app. ( Output/Result )

Hi @v-prasadboke,
Thanks for that. Have you noticed the aka.ms link leads to 404: https://aka.ms/sentinel-CyberArkAudit-functionapp?

Reason being the hyperlink we have used in Shortlink leads to master branch. And this Solution is not in master branch yet.
That is the reason.
Thanks for sharing the screenshots.

Hello @nitsan-tzur, any reasons behind changing the Data connector folder structure

Hello @nitsan-tzur, Sorry for the late reply.
I'll have to check once on the folder structure.

Hello @nitsan-tzur, Sorry for the late reply. I'll have to check once on the folder structure.

Hi @v-prasadboke
Thanks for looking into it. Any update on this check?

Hello @nitsan-tzur, And sorry for the late reply.
Function app's Folder structure is incorrect. We are working on it and I'll push the changes by tomorrow 27 March, 2024

Hi @v-prasadboke ,
Thanks for the update. Will the PR be approved with this change?

Hello @nitsan-tzur,
Folder structure corrected. But function.json is missing from the folder.
Please add it.
You can refer this one. Solutions/Box/Data Connectors/AzureFunctionBox/function.json
It should be placed in Functionapp zip as well.

Hello @nitsan-tzur, Folder structure corrected. But function.json is missing from the folder. Please add it. You can refer this one. Solutions/Box/Data Connectors/AzureFunctionBox/function.json It should be placed in Functionapp zip as well.

Hi @v-prasadboke,
It seems like repackaging is breaking the deployment. Might be due to movement of requirements.json. Just tried to deploy the new zip and function is empty:

Have you added function.json file

Yes. Same result with the function.json file
Get Outlook for iOShttps://aka.ms/o0ukef

From: v-prasadboke @.>
Sent: Friday, March 29, 2024 4:51:22 AM
To: Azure/Azure-Sentinel @.>
Cc: Nitsan Tzur @.>; Mention @.>
Subject: Re: [Azure/Azure-Sentinel] Cyberark Audit service integration (PR #10062)
CyberArk Security Warning: This is an external email!
Have you added function.json file
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/Azure/Azure-Sentinel/pull/10062*issuecomment-2026897043__;Iw!!Pe07N362zA!30l4XiLtr1YGAva-BdGch-DwUT-1eG8DvnrrALY2F3n9MBDv7OgtTM30Ec3BILiMNVATbo_EyrjyD-Sc5MdKN9PRsOdv$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/BEQBXFL4AQ7GSLUBTQTNOBDY2UTQVAVCNFSM6AAAAABD4TRB26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRWHA4TOMBUGM__;!!Pe07N362zA!30l4XiLtr1YGAva-BdGch-DwUT-1eG8DvnrrALY2F3n9MBDv7OgtTM30Ec3BILiMNVATbo_EyrjyD-Sc5MdKN-_vQda1$.
You are receiving this because you were mentioned.Message ID: @.***>

I can see connector on my end

Hi @v-prasadboke ,
Thanks for your review.
What should be the permeant aka.ms link to the zip package in the deployment template?


[Sensorname] become unavailable

Roughly every 3 minutes, the sensor will become unavailable with the following entries in the log file:
[Sensorname] became unavailable
4:05:27 AM - In 1 second
[Sensorname] Online became unavailable
4:05:27 AM - In 1 second
[Sensorname] Heating became unavailable
4:05:27 AM - In 1 second
It resumes after about a minute.

I'm guessing this is UWG4 related? Since all of my sensors have been available since I've updated this morning.
@adamjernst are you experiencing similar issues?

Yeah I've seen this too. Need to investigate and add some logging. Not sure if it's transient API issues or what.

I see it much more intermittently—only every few hours. I do suspect it might be related to transient timeouts, as mentioned in #139. I am adding more logging to my local instance to see what I can determine.

@gessl A logging patch I am using locally:
diff --git a/custom_components/ojmicroline_thermostat/coordinator.py b/custom_components/ojmicroline_thermostat/coordinator.py
index 0c4b877..f9b0b6e 100644
--- a/custom_components/ojmicroline_thermostat/coordinator.py
+++ b/custom_components/ojmicroline_thermostat/coordinator.py
@@ -54,13 +54,24 @@ class OJMicrolineDataUpdateCoordinator(DataUpdateCoordinator):
             UpdateFailed: An error occurred when updating the data.

         """
+        _LOGGER.debug("Updating data")
         try:
             async with async_timeout.timeout(API_TIMEOUT):
                 thermostats = await self.api.get_thermostats()
+                _LOGGER.info(
+                    "Fetched thermostats: %s",
+                    ", ".join(t.serial_number for t in thermostats),
+                )
                 return {resource.serial_number: resource for resource in thermostats}

         except OJMicrolineAuthError as error:
+            _LOGGER.warning('Auth error updating data')
             raise ConfigEntryAuthFailed from error

         except OJMicrolineError as error:
+            _LOGGER.warning('Error updating data: %s', error)
             raise UpdateFailed(error) from error
+
+        except Exception as e:
+            _LOGGER.warning('Unknown error updating data: %s', e)
+            raise

You will need to bump up the log level for this component using e.g. the Developer Tools → Services pane:
service: logger.set_level
data:
  custom_components.ojmicroline_thermostat: debug

I am waiting for the issue to reproduce, but it's pretty rare for me. If you can reproduce and get logs please share them here!

@adamjernst I did that and suddenly it is happening scarcely. I have seen one unavailable but I hadn't set the log levels correctly. I wonder if adding logging provides enough delay to make this problem rarer? I'll post a log once I catch something useful.

Probably doing something wrong with the logging. Had an unavailable event but am not seeing the custom log entries.

Hmm odd. Let's wait and see if it reproduces for me.

I'm seeing the same behavior where a thermostat goes unavailable without anything obviously wrong in the logs. Time for… more logging! Stay tuned...

My new theory is that the API is simply returning Thermostat models with online=False, which nukes all the data and results in the symptoms you're seeing. If I verify that assumption, we can discuss what to do about it.

I have to admit I'm fairly fresh to HA but as such I have observed that other entities go unresponsive too, such as nest cameras and there is no clear reason why that would be. Maybe this is what you are getting at with Thermostat returning online=false, i.e. it's some HA behavior that is actually contributing to this?

@gessl unfortunately we cannot blame HA here 😉 The online=False actually is returned by the python-ojmicroline package (which both Adam and I did a bunch of work in).
@adamjernst  Maybe the API used is unstable/unreachable at times? Maybe add a ping sensor to the host used by your Thermostat, just to make sure the problem is the package, not the server?

@robbinjanssen I still haven't reproduced the issue, but my guess is that both the API & python package are perfectly fine but the thermostat itself has dodgy wifi (your original guess!) — and thus the API just returns a Thermostat with online=False and no data.
If I verify that this is the case, the question is what to do about it. I lean towards modifying the coordinator class to serve stale data for a few minutes; if the thermostat doesn't come back online within ~5 minutes, it should revert to serving what the API is actually giving.
This problem would also be solved if we switch from cloud-polling to using the notifications-based API. So I might just do that and be done with the whole thing.

@adamjernst For what it's worth I have not seen it go unavailable for more than a minute, so the idea to serve stale information might work well in practice just from what I have seen. If there is a clean solution that would of course be best.

@adamjernst

This problem would also be solved if we switch from cloud-polling to using the notifications-based API. So I might just do that and be done with the whole thing.

Do you have more information about the notification based API?

@robbinjanssen Sure! It's just HTTP long poll on an endpoint /notification, e.g.:
https://mythermostat.info/api/notification?sessionid=REDACTED&sequencenr=0
If something changes, a payload like the following is delivered:
{
    "SequenceNr": 3,
    "Action": 2,
    "Thermostat": {
        "SerialNumber": "1414444",
...

If nothing changes, the request times out after 60 seconds and the request is retried.
A few notes:

Interestingly the sequencenr  parameter is always 0, although the payload does include a sequence number. Seems like they never quite finished the job, and I would expect it's possible to drop notifications if your timing is bad; normally a sequence number would ensure you're getting every notification, but I guess they didn't finish it…
Using this doesn't reduce the total number of requests we make to the API, since we're still making a request every 60 seconds. But presumably this notification request is cheaper than requesting all thermostat data every 60 seconds.
The other principal advantage to this notification approach is that we get faster updates (near-instant instead of waiting for the next poll interval) and we no longer have to worry about the weird propagation issues that happen with polling.
There is also a separate long-polling endpoint that listens for new thermostats, but I feel like that's rare enough to be a non-issue.

OK, I think reproduced this issue:
2024-02-17 10:54:48.797 INFO (MainThread) [custom_components.ojmicroline_thermostat.coordinator] Fetched thermostats: XXXXXX1, XXXXXX2, XXXXXX3
2024-02-17 10:54:48.797 DEBUG (MainThread) [custom_components.ojmicroline_thermostat.coordinator] Thermostat XXXXXX1 has online True vacation 2024-02-12 00:00:00-06:00 thru 2024-02-16 00:00:00-06:00
2024-02-17 10:54:48.797 DEBUG (MainThread) [custom_components.ojmicroline_thermostat.coordinator] Thermostat XXXXXX2 has online False vacation 2024-02-12 00:00:00-06:00 thru 2024-02-16 00:00:00-06:00
2024-02-17 10:54:48.798 DEBUG (MainThread) [custom_components.ojmicroline_thermostat.coordinator] Thermostat XXXXXX3 has online True vacation 1970-01-01 00:00:00-06:00 thru 1970-01-01 00:00:00-06:00
2024-02-17 10:54:48.798 DEBUG (MainThread) [custom_components.ojmicroline_thermostat.coordinator] Finished fetching ojmicroline_thermostat data in 0.399 seconds (success: True)

This results in the following logbook entries:
Bunkroom Bathroom Floor Online  was connected
10:55:48 AM - 12 hours ago
Bunkroom Bathroom Floor Online  was disconnected
10:54:48 AM - 12 hours ago

That's subtly different from what you describe, @gessl; you say that your sensors are marked unavailable, not disconnected...

@adamjernst I'm not sure. As you see above when it comes back it says floor (my thermostat's name) Online is connected. But it drops as "unavailable". But notice that in #139 I noted both an Error and a timeout, and have seen both. In short, I'm not sure but this could well be the same phenomenon just reporting slightly differently. Interestingly I had ping running and pings are not disrupted.

Does the WD5 API have a similar endpoint?

I'd have to reverse engineer the app for that again, as there is no documentation about the WD5 API. I'll try to figure it out asap

After looking back on some older posts on the HA community forum, I might have found something.
https://community.home-assistant.io/t/mwd5-wifi-thermostat-oj-electronics-microtemp/445601

GET https://owd5-mh015-app.ojelectronics.com/ocd5notification/negotiate?clientProtocol=1.3

Response:
{
    "ConnectionId": "7fe6ba31-be25-44cb-ac72-6b62e3ce5ecb",
    "ConnectionTimeout": 110.0,
    "ConnectionToken": "3H5PCkeD1lLHiLvVS0xklpe5apgHYIudkycXcHbUwFv2Qzy/4EFQF8SXwBT7fssqUb4UpnwIGoNsnH63nl1+M/Av2/L3fo/3UinL42Yqphf9Br3fQyeGStSXJ4kirwpc",
    "DisconnectTimeout": 30.0,
    "KeepAliveTimeout": 20.0,
    "LongPollDelay": 0.0,
    "ProtocolVersion": "1.3",
    "TransportConnectTimeout": 5.0,
    "TryWebSockets": true,
    "Url": "/ocd5notification"
}

----

GET https://owd5-mh015-app.ojelectronics.com/ocd5notification/connect?transport=serverSentEvents&connectionToken=3H5PCkeD1lLHiLvVS0xklpe5apgHYIudkycXcHbUwFv2Qzy%2F4EFQF8SXwBT7fssqUb4UpnwIGoNsnH63nl1%2BM%2FAv2%2FL3fo%2F3UinL42Yqphf9Br3fQyeGStSXJ4kirwpc&connectionId=7fe6ba31-be25-44cb-ac72-6b62e3ce5ecb
No response

This is a call to some sort of ocd5notification endpoint, is yours similar?

Seems like this is it, there is some negotiation and connect going on here:

But then one stream gets stuff like:
{
  "C": "xxx|hmu,5",
  "M": [
    {
      "SequenceNr": 2,
      "Groups": [],
      "Thermostats": [],
      "ThermostatRealTimes": [
        {
          "Action": 2,
          "Id": xx,
          "SerialNumber": "xx",
          "Online": true,
          "RoomTemperature": 2077,
          "FloorTemperature": 2008,
          "Heating": false,
          "SensorAppl": 3
        }
      ]
    }
  ]
}

So I was able to reproduce this ping-pong in python, all 3 calls are needed to get the notification.
The first one is to /negotiate, it gives me a connectionId and connectionToken.
The second one can be fired together with the third one. The /send endpoint is a POST with the connection ID and Token and the body contains the session ID. The /connect is the keep-alive stream that receives all the data.
You only require one call, right @adamjernst ?

@robbinjanssen correct! If you build notification support for WD5 thermostats and just leave it unimplemented for WG4, I will fill it in and test it...

I'll open up an issue in the python-ojmicroline repo :-)


Can't restart the app after closing the main window. Running kivy in a separate thread

Software Versions

Python: 3.7.7
OS: Win/Mac/Linux
Kivy: 2.0
Kivy installation method: pip install --user kivy[base]

Describe the bug
Trying to restart the application doesn't work. I am running kivy from a separate thread.
Expected behavior
You should be able to reload the app after you closed the main window without killing the main thread
The workaround proposed here https://groups.google.com/g/kivy-users/c/yfhH7skAEJA  is not working in kivy 2.0..
def reset():
  import kivy.core.window as window
  from kivy.base import EventLoop
  if not EventLoop.event_listeners:
      from kivy.cache import Cache
      window.Window = window.core_select_lib('window', window.window_impl, True)
      Cache.print_usage()
      for cat in Cache._categories:
          Cache._objects[cat] = {}

# run multiple times
reset()
TestApp().run()
reset()
TestApp().run()
...

The short answer is that kivy does not support this currently and if you want to do it you should run kivy in a second process.
However, it may be doable depending on your app, but it requires messing with some kivy internals so I cannot recommend it. That said, here's an example of how to do it: https://github.com/matham/pytest-kivy/blob/master/pytest_kivy/app.py#L90.

The short answer is that kivy does not support this currently and if you want to do it you should run kivy in a second process.
However, it may be doable depending on your app, but it requires messing with some kivy internals so I cannot recommend it. That said, here's an example of how to do it: https://github.com/matham/pytest-kivy/blob/master/pytest_kivy/app.py#L90.


Typescript's type aliases are not resolved in Vue components

In my tsconfig.json file I specify the following path alias:
{
    "paths": {
      "~/*": ["src/*"]
    },
}

And then in a VueJS component I might import a dependencies like so:
import { TrueFalse, icon, isTrue } from "~/components/shared";

Vite compiles the source without issue and vite-plugin-dts also creates declaration files but as you can see below, the ~/ type alias is still present in the type which makes it unusable as an exported type file.

Historically, when using Rollup directly I have used a combination of the ts-patch npm module and the typescript-transform-paths module:

ts-patch - patches Typescript's tsc to allow it to use the Typescript plugin API
typescript-transform-paths addresses converting type aliases back to full file paths

With this done, you just add the plugins to your tsconfig.json file like so:
{
    "plugins": [
      // Transform paths in output .js files
      { "transform": "typescript-transform-paths" },

      // Transform paths for declarations files
      { "transform": "typescript-transform-paths", "afterDeclarations": true }
    ]
}

This works and I've never found a way to get TYPES to export using the alias Rollup plugin (which is what ViteJS uses I believe). In any case, I'd really like to run everything in ViteJS and your plugin "almost" works ... hoping we can get path aliases incorporated.

Actually it's funny, my traditional means of doing this is nicer in that all aliases are resolved but considering the .d.ts is a TS file I guess maybe TS's built in aliases should work?

Would you share your vite.config.ts and tsconfig.ts files?
I think this requires some testing with other plugins.

Hi @qmhc I was just coming back to this issue as I've confirmed that Microsoft has been asked many times about whether .d.ts files should follow path aliases (since they are part of the TS spec) but their position is that it should not follow them and I guess there are likely good performance reasons for this stance. That said, it does make this that much more important to solve for.
The ts-patch approach I've alluded to above does work perfectly when using tsc as the underlying engine for transforms. I use this in dozens of repos for this purpose but unfortunately it doesn't pair well with this plugin at the moment.
I had a look at your deps and i would appear you're passing the DTS generation over to tsup. I think anything from @egoist is worth building around and I've been meaning to use TSUP a lot more rather than rolling my own configuations but I'm not aware of how TSUP works under the hood and how to ensure that tsc's plugin API is enabled properly.

You had asked about my configuration files, so here they are:
tsconfig.json
{
  "compilerOptions": {
    "module": "es2020",
    "target": "es2020",
    "lib": ["DOM", "ESNext"],
    "strict": true,
    "esModuleInterop": true,
    "incremental": true,
    "skipLibCheck": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "noUnusedLocals": true,
    "strictNullChecks": true,
    "forceConsistentCasingInFileNames": true,

    "baseUrl": ".",
    "declaration": true,
    "outDir": "dist",

    "paths": {
      "~/*": ["src/*"]
    },
    "types": ["vite/client"],
    "plugins": [
      // Transform paths in output .js files
      { "transform": "typescript-transform-paths" },

      // Transform paths for declarations files
      { "transform": "typescript-transform-paths", "afterDeclarations": true }
    ]
  },
  "include": ["src"],
  "exclude": ["dist", "node_modules", "**/*.spec.ts"]
}

vite.config.ts
import path from "path";
import { defineConfig, UserConfig } from "vite";
import Vue from "@vitejs/plugin-vue";
import WindiCSS from "vite-plugin-windicss";
import Icons from "unplugin-icons/vite";
import IconsResolver from "unplugin-icons/resolver";
import Inspect from "vite-plugin-inspect";
import Components from "unplugin-vue-components/vite";
import PC from "vite-plugin-particle-components";

export default defineConfig({
  resolve: {
    dedupe: ["vue"],
    alias: {
      "~/": `${path.resolve(__dirname, "src")}/`,
    },
  },
  publicDir: false,
  build: {
    lib: {
      name: "particle-components",
      entry: path.resolve(__dirname, "src/known-components.ts"),
    },
    minify: "esbuild",
    rollupOptions: {
      external: ["vue"],
      output: {
        globals: {
          vue: "Vue",
          router: "VueRouter",
        },
      },
    },
  },

  plugins: [
    Vue(),
    WindiCSS(),
    Components({
      resolvers: [IconsResolver()],
      dts: true,
      extensions: ["vue"],
    }),
    Icons(),
    Inspect(),
    PC(),
  ],
} as UserConfig);

I do wonder if maybe this issue needs to be brought over to TSUP as the actual engine for building the declaration files needs to resolve these path aliases either by some means of it's own or by using the containing repo's instance of tsc (as my instance has been patched to use the Typescript plugin API).

Ok I ran TSUP locally in a which doesn't have any Vue components (aka, so the Vue loader isn't needed) and it transpiled perfectly down to a single typed file. However, when I then added this plugin to the same repo it created the types not in a single file but rather in a tree structure which mimics where the types are defined:

and then in the files which utilize the path alias it fails, as you can see in this screenshot:

My configuration files are:
vite.config.ts
import path from "path";
import { defineConfig, UserConfig } from "vite";
import Vue from "@vitejs/plugin-vue";
import WindiCSS from "vite-plugin-windicss";
import Icons from "unplugin-icons/vite";
import IconsResolver from "unplugin-icons/resolver";
import Inspect from "vite-plugin-inspect";
import Components from "unplugin-vue-components/vite";
import PC from "vite-plugin-particle-components";
import dts from "vite-plugin-dts";

export default defineConfig({
  resolve: {
    dedupe: ["vue"],
    alias: {
      "~/": `${path.resolve(__dirname, "src")}/`,
    },
  },
  publicDir: false,
  build: {
    lib: {
      name: "particle-components",
      entry: path.resolve(__dirname, "src/known-components.ts"),
    },
    minify: "esbuild",
    rollupOptions: {
      external: ["vue"],
      output: {
        globals: {
          vue: "Vue",
          router: "VueRouter",
        },
      },
    },
  },

  plugins: [
    Vue(),
    WindiCSS(),
    Components({
      resolvers: [IconsResolver()],
      dts: true,
      extensions: ["vue"],
    }),
    Icons(),
    Inspect(),
    dts(),
    PC(),
  ],
} as UserConfig);

tsconfig.json
{
  "compilerOptions": {
    "module": "es2020",
    "target": "es2020",
    "lib": ["DOM", "ESNext"],
    "strict": true,
    "esModuleInterop": true,
    "incremental": true,
    "skipLibCheck": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "noUnusedLocals": true,
    "strictNullChecks": true,
    "forceConsistentCasingInFileNames": true,

    "baseUrl": ".",
    "declaration": true,
    "outDir": "dist",

    "paths": {
      "~/*": ["src/*"]
    },
    "types": ["vite/client"],
    "plugins": [
      // Transform paths in output .js files
      { "transform": "typescript-transform-paths" },

      // Transform paths for declarations files
      { "transform": "typescript-transform-paths", "afterDeclarations": true }
    ]
  },
  "include": ["src"],
  "exclude": ["dist", "node_modules", "**/*.spec.ts"]
}

I was digging around in your source code and realized that tsup is used to build this plugin but you aren't wrapping it's capabilities into this plugin. Guess that explains why they behave differently 😝

Thanks for your research first!
This plugin is using ts-morph (you can find it in package.json -> dependencies) to create typescript programs and source files, and using typescript LanguageService to emit output files. Finally it using some regular expressions to further process the .d.ts files in outputs.
After I did some debugging, I found there is a problem in judging whether a path is alias path when alias find (is the key when using key-value config) includes '/'.
Currently a workaround is to change the alias config in vite.config.ts:
import path from 'path'
import { defineConfig } from 'vite'

export default defineConfig({
  resolve: {
    alias: {
      '~': path.resolve(__dirname, 'src')
    }
  }
}

@qmhc many thanks for looking into this; i'll use the workaround for now. Any sense for when this will be fixed? No pressure, just aware that my own attention is spread quite thinly and want to keep an eye out for it if its relatively soon.

Great. Many thanks. I did a little reading on ts-morph last night ... looks really useful as my normal experience with AST's has been quite painful.


special character support - bug

With special characters in the password, I can use the encoding (@ = %40), but this doesn't work for all the targets.
The typing should happen in the standard way (typing @) and the scripts should take care of encoding special characters if necessary.
EDIT:
The bug was: I used encoding (%40) but apt gave a proxy authentication error. With non-encoding it works.

The %40 hack was introduced when I had trouble handling it. Also mentioned here @ askubuntu.
Can you share some more details how did it work?
http://username<EMAIL_ADDRESS>
Please try more permutations of the same and share results. Other people could also benefit for the same.

@kaktus42 It works for me. Could you share more details? Please close the issue if it is resolved for you.


Windows (or at least File explorer) session manager (at least save and restore)

Description of the new feature / enhancement
It would be very useful to have a Windows (or at least File explorer) session manager (at least save and restore);
that would also keep the expected windows' sorting / order !
to compensate for the lack of windows features regarding file explorer windows/tab management, and regarding session management.
Scenario when this would be used?
Every day's work...
To manage files, (multiple) work on-going...
Supporting information
No response

/feedbackhub


Bank account: Infinite loading when adding existing bank account again

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Login with any account, go to Workspace => Connect Bank Account => Choose Plaid.
Add a bank account with plaid that you already added it, now it's showing the error, reload the page.
Notice that it shows the infinite loading, close the page, go to the workspace => connect bank account again.
Notice that it shows the infinite loading.

Full Reproduction Steps

Go to account settings -> payments -> Add Payment method. Click the bank account option
Log into plaid, and select the bank account number you'll be going with. In this case, I added the one ending in x1111
After adding it successfully, go to workspace. Create a new workspace if you need to
Now "Connect Bank Account" within workspace settings
Log into plaid. Select Chase so you can select which accounts to transfer over. Only select the x1111 account.

Expected Result:
There's no infinite loading
Actual Result:
There's infinite loading
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.2.48-2
Reproducible in staging?:  y
Reproducible in production?: could not check
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/210599168-e7fd0894-463c-429e-8227-9e12b4dbb044.mov
https://user-images.githubusercontent.com/43996225/210599131-93969c7a-c86b-4728-8e5a-c50deb1a5822.mp4
Expensify/Expensify Issue URL:
Issue reported by: @hungvu193
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1672765951849519
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01a17a6139da65315e
Upwork Job ID:<PHONE_NUMBER>898729472
Last Price Increase: 2023-01-17

I haven't been able to test but will review it tomorrow.

@marcochavezf - I'm adding engineering to review if this is something we should block if the account was already added instead of letting the user start the flow again. Thanks!

Not overdue, the label was added over the weekend.

@marcochavezf have you had a chance to test at this one?

@kavimuru To clarify repro steps, did you add the bank account as a payment method first? Than tried to add that bank account to a workspace?

I can take this @marcochavezf if you don't mind 🙇 . Other wise feel free to take it back :)

So I was able to reproduce by adding the bank account as a payment method first, which should be stated in the reproduction steps to make things super clear. Going to update the description

Thanks, @ctkochan22 for the update-- should apply the Internal label?

So the logic is falling through here: https://github.com/Expensify/App/blob/34fc98f34668de447a490639f5bdc0429a0e1380/src/components/AddPlaidBankAccount.js#L122-L132
We show the loader if the token is missing OR plaid is loading. If not we then check if there is an error message. If there is an error message, we display it. Lastly if there is a token present, we show the Plaid data (selector or the redirect link).
These are in separate "if" statements, which does not make it mutually exclusive. So when we reload the page after no bank accounts have been found, we enter that block.
Token is gone upon refresh. Bank accounts are missing. So we default to spinner.
Solution
I think we should only show the spinner if

We are loading something still
Token is empty and there is no error message present

@nkuoch Let me know if you see any issue with this

Oh this was fixed https://github.com/Expensify/App/issues/13985
I'm not sure its not showing up here.

I'm going to reopen to identify if I need to proceed forward with the payment next steps.

@hungvu193 - I sent an invite in Upwork. Please accept since you found this bug and I can complete the payment process. Thanks!

Here is what I see in Upwork, can you double-check if I found the right person:

Thanks!

@alexpensify yeah that's me, not sure why it didn't appear on my upwork, can you please rehire?

Nevermind,I accepted the invitation:D

All good, I sent an offer now via Upwork.

Closing - the process has been completed in Upwork!

@aimane-chnaif thanks for flagging. I'll work on the process today.

I've run out of time today and will work on the payment in Upwork tomorrow for C+. Sorry, I missed this part in my previous process.

@aimane-chnaif - thanks again for catching this honest mistake on my end. I have started the process in Upwork. Please reply once you confirm this GH can be closed. Here is the upwork job:
https://www.upwork.com/jobs/~01754b83bcbf760b7b

Cool, I'm closing this GH.

Ok, let me review what's going on in Upwork.

Alright, the payment should be on the way now. @aimane-chnaif can you please confirm? Once I get confirmation, I'll close this GH. Thanks!

Perfect! Thanks for the update.


HDMI not working

I install mac os monterey in my x1carbon with your EFI config. Everything is working pretty smooth but the HDMI is not working at all. Is there any fix for that.
Thanks in advance.

After performing Other tweaks

Enable HiDPI

The HDMI is working


Fix CI failures

Two of the actions that we use: action-android, and
junit-report-annotations-action use the deprecated set-env command. As a
result, CI was failing.
This change includes a temporary workaround.
These workarounds will be removed, once:

malinskiy/action-android is updated to not use set-env.
We create a fork or contribute to junit-report-annotations-action.


Stopped working on 12.07.63

The module has stopped working on the latest YT update 12.07.63.

Existing issue already in progress. Closing this.


[BUG] : Resizing the buttons  and correct their alignment  and also some other neccessary changes for better visual appeal to a user.

Description
the buttons are not sized properly which looks very uneven to the user . and also some other changes to improve its its visual experience ,
Screenshots

Any additional information?
please assign me this issue . I want to work on this issue .
What browser are you seeing the problem on?
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I'm a GSSoC'24-Extd contributor
[X] I'm a Hacktoberfest'24 contributor
[X] I am willing to work on this issue (optional)

@vishanurag i want to work on this issue please assign me this with labels as gssoc;24 extd and level tag .

Hello, I've fixed this issue!
This is what I've done:
I've made several changes to improve the button sizing and overall visual experience of the Canvas Editor. I updated the CSS in the src/Styles/Style.css file to create a more consistent and visually appealing button design. Here's a summary of the changes:

Standardized button sizes and styles across different sections.
Implemented a soft, pastel color scheme using pink and blue tones.
Added hover effects and subtle animations to enhance user interaction.
Improved button spacing and layout for better visual hierarchy.
Ensured consistency in border-radius, padding, and font sizes.

These changes should address the issue of uneven button sizing and enhance the overall visual experience for users.
I also created pull request: https://github.com/vishanurag/Canvas-Editor/pull/1139

[!CAUTION]
Disclaimer: This fix was created by Latta AI and you should never merge before you check the correctness of generated code!

This bug was fixed for free by Latta AI - https://latta.ai/ourmission


Implement class utils::Coords (cpp)

Inspired by Python module Shapes.coord_2d.py

Completed; Still to be tested.


run load handlers on next frame

Noticed that triggering UI changes from _onload triggered all sorts of deopts. Although people should probably be aware, making sure it doesn't deopt will make it so people don't accidentally forget. Great when integrating with third party libraries where you're not necessarily sure what's happening under the hood.
Also snuck in a quick check into the example so it can be run without any issues in Node. Yayay.

v3.0.2


Handle request "credentials" for browser-like environments

GitHub

Related to https://github.com/mswjs/msw/issues/189

While there is no way to backward-engineer xhrReq.withCredentials, NRI must ensure that whenever the credentials (cookies) were sent, they will be available on the intercepted req instance (under req.cookies).


Handle ERROR_INVALID_PARAMETER error for GetVolumeInformationW win32 api

similar to https://github.com/elastic/gosigar/pull/159
GetVolumeInformation will fail for external drives like CD-ROM or other type with error codes as ERROR_NOT_READY. ERROR_INVALID_FUNCTION, ERROR_INVALID_PARAMETER and could be others.
The PR will report error in the logs but ignore it and move further. We consider retrieving filesystem type best efforts.
Since we introduced this calculation we are getting too many issues related to external drives, so we need to decide on one of the following behaviors:

revert https://github.com/elastic/beats/issues/22501 which is causing these scenarios
report error and ignore it (this is what this PR is doing, we need to handle it on the helper.go side in the beats code)
ignore error, no report in the logs since it complicates code by adding checks for this error occurrence

@jsoriano have we dealt with anything similar before? @fearful-symmetry which option would you go for?

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2021-11-01T13:36:39.411+0000

Duration: 7 min 18 sec

Commit: 6d4da4c5f20696612e77c2a8d4e5bdad77648e2b

Test stats :test_tube:

Test
Results

Failed
0

Passed
261

Skipped
7

Total
268

I think the error in this case can be completely ignored (third option). I would prefer that than to report it here but ignore it in beats. Ignoring it in beats can lead to other problems, as actual errors in other platforms being ignored by mistake. So I would prefer to make the platform-specific decision here.
Not reporting the filesystem for drives without a filesystem is probably fine in these cases, I guess this can even happen with a  hard disk without format or partition table?
There would be a couple of things to think about:

What value to report. No value or empty value sgtm, but maybe we want to put something like unknown or unavailable?
Do we have the complete list of known errors? This way we can ignore the errors that may happen when the filesystem is not available, but we report other issues. Though this may add complexity and provide little value.

@jsoriano , thanks for the quick feedback
Same here, third option gives us less headache, as we would have to single out this specific error from the rest and ignore it, ex:
if !strings.Contains(err.Error(), "GetVolumeInformationW") {
			return nil, err
		}

not a big fan of string comparison.

What value to report. No value or empty value sgtm, but maybe we want to put something like unknown or unavailable?

I like the idea and I would go for unavailable since this is the main issue.

Do we have the complete list of known errors? This way we can ignore the errors that may happen when the filesystem is not available, but we report other issues. Though this may add complexity and provide little value.

This is how I fixed the last scenario https://github.com/elastic/gosigar/blob/master/sys/windows/syscall_windows.go#L356, but now we have a new error type ERROR_INVALID_PARAMETER which is most likely caused by the external drives.
These are system error codes and they are very broad: each one can occur in one of many hundreds of locations in the system, also the list is very large.

What value to report. No value or empty value sgtm, but maybe we want to put something like unknown or unavailable?

I like the idea and I would go for unavailable since this is the main issue.

Btw, I was checking what is done in Linux for this case, and I found that the behaviour is different. On Linux sigar only collects mounted filesystems, so all of them have a filesystem type. While in Windows it collects all drives, mounted or not.


add: pair-angular logo 👩💻👨💻

This PR adds the Logo of PairAngular to the AngularLogos Site.

@SiddAjmera Thank you for your PR! 🙏
Can you please change the filename to pair-angular.svg

@fmalcher does the SVG look good to you?

@maartentibau @SiddAjmera Yes! The margin COULD be fixed, but it's not that big so I'm sure we can ignore it.
Thanks!


creates Button component (Eingabe, Shuffle, Löschen)

Looking good. I just changed btn container fixed width to max-width to make the buttons more responsive on super small phones.


Advantage to converting data to upper case?

Hi @emedvedev,
Is there an advantage to force the dataset to uppercase rather than having separate classes for upper and lower case? I think that the accuracy is hurting for having to map two classes two one? I would train with no-force-uppercase but I have been training Synth90k with default parameters for over a month and wanted your advice before retraining.
Best regards,
Vishal

It might turn out than no-force-uppercase would indeed be better than the default when in comes to Synth90k, but I can't predict by how much :)
Note that the fonts and distortions in Synth90k images are already varied enough that it's not quite as simple as "two classes" for uppercase and lowercase though. Even if you get improved accuracy, don't expect a very significant improvement. Wouldn't hurt to try though!

Thank you so much. I will try training in google CloudML with multi-gpu.

Hi,
The code currently doesn't support training with multi-gpu, does it? Any direction to how I can get it implemented would be much appreciated.
Best regards,
Vishal

It does not, and unfortunately I don't have any experience with multi-gpu training, so you're on your own. :)
I'm going to close this issue, because the original problem has been addressed, but feel free to open a new one if you run into problems with the codebase.


Error: max retries exceeded

What is the issue?
I am in a place with a slow ADSL connection that works for loading pages and checking emails. However, I can't pull LLM models because it's regularly interrupted by an 'Error: max retries exceeded after about 2 or 3 minutes. If I use my phone with Share Connection, it works well in 5G.  I haven't tried with other LLMs but the previous version worked fine in the same machine, same config with llama3:
(base) douglas@ubuntu:~$ ollama run llama3.1
pulling manifest
pulling 4f6dc812262a...   0% ▕                                                                                ▏  12 MB/4.7 GB
Error: max retries exceeded: Get "https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4f/4f6dc812262ac5e1a74791c2a86310ebba1aa1804fa3cd1c216f5547a620d2f2/data?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=66040c77ac1b787c3af820529859349a%!F(MISSING)20240807%!F(MISSING)auto%!F(MISSING)s3%!F(MISSING)aws4_request&X-Amz-Date=20240807T171933Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=f5827dcdc260bbfff08f9d872ac5f2ed2b1049f7789c151b9802267049bcc08a": dial tcp [2606:4700::6812:95a]:443: i/o timeout

In fact, when I pull a small model, it works well. No problem pulling phi3:mini, but ollama pull llama3.1:405b-instruct-q2_K cannot pull more than 200K without error.
igor@Mac-Studio-192 ~ % ollama run phi3:mini
pulling manifest
pulling 633fc5be925f... 100% ▕████████████████▏ 2.2 GB
pulling fa8235e5b48f... 100% ▕████████████████▏ 1.1 KB
pulling 542b217f179c... 100% ▕████████████████▏  148 B
pulling 8dde1baf1db0... 100% ▕████████████████▏   78 B
pulling 23291dc44752... 100% ▕████████████████▏  483 B
verifying sha256 digest
writing manifest
removing any unused layers
success

Send a message (/? for help)

People will keep running into this issue and more and more tickets will be created unless the project maintainers help to make the model downloader more robust by pulling this pending PR as a step in the right direction.
https://github.com/ollama/ollama/pull/4625

Closing for https://github.com/ollama/ollama/issues/2006

how to solve this problems?I met this error now.

@liuwq999 It's a matter of the number of simultaneous threads used to pull a model. It was set too high, and although it was lowered, it still wasn't enough. This issue is now closed, and the discussion has moved to this other issue. Please post your message there.
https://github.com/ollama/ollama/issues/2006


custom path

The idea would be to pass a custom-predefined path, i.e. an orbit for a satellite or the flying path. This kind of data could be something like: https://isstracker.pl/en

We could probably have a better constructor to be fair...


can't swipe with the new update 9.0.1

was working fine on v8.x.x, after upgrading to 9.0.1 I can't swipe between containers, its does the swap internally but the actual container aint moving, if you resize the window it works again as expected.
"ngx-swiper-wrapper": "^9.0.1",
"@angular/animations": "^9.1.0",
"@angular/cdk": "^9.2.0",
"@angular/common": "~9.1.0",
"@angular/compiler": "~9.1.0",
"@angular/core": "~9.1.0"
setTimeout(() => {
 window.dispatchEvent(new Event('resize'));  // Temporally fix
}, 1000);

You can set observer to true in config. And swiper update automatically, but it goes to the end((

the first slide change goes straight with no animation, then it works with animation aswell


Very fast read after interupt of PCA9655E

Hello,
again I search for a good idea.
I use a PCA9655E as input, no problem to read over socket interface after a interrupt show a change on the inputs. But I must press the button around 250ms to get the right information because

PIGPIO see interrupt
notify my application
I send a read-command to PIGPIO
PIGPIO read the status
...but if the button pressed to short, the real value is gone...

I think writing a PIGPIO-script could be very much faster.

Start script when interrupt go to 0 (wait x)
read input value (I2CRW handle register)
...but how I get this input-value that is "stored" there?
Is there a way to send it via socket interface?
Can I read this result from the socket interface?

Joachim

I don't entirely understand your application or how you're interacting with the socket API, but I'll give it a shot.
It seems to me that if you use a script as you propose, you then have two problems in your client code:

Figure out when the interrupt occurred
Figure out what value was read by the script when the interrupt occurred.

Let's address the what first.  The script_status command (PROCP) returns, in addition to a status code, the current values of all 10 "parameter" registers used by the script.  As long as your script stores the result of its read in p0-p9, you can observe these results by calling script_status.
As for the when, the simplest solution is probably to have your client register for the same interrupt that your script waits on.  By the time the client receives the notification and sends a script_status command to the server, the script should have finished performing the read and storing it in a parameter register.
All of this will work reasonably only for relatively infrequent interrupts.  If multiple interrupts might occur in the time it takes for the client to be notified, send a query, and get a response, you'll lose events.
In that case you might have some luck looking into the "event"-related commands.  If you only have a few GPIOs that you're monitoring, you could use event_trigger command (EVT) in your script.  On the client end, you would use event_callback or wait_for_event to be notified about events, rather than GPIOs.  You'd have to assign meaning to a very small set of events (i.e. maybe event 0 means "GPIO 5 falling" and event 1 means "GPIO 5 rising").
This should pretty much guarantee you never lose information, at the cost of supporting only a small number of GPIO pins.

Just be aware that EVT in script has a bug.  The following quote is a reply from joan re issue #148.

There is an error within the pigpio scripts code which will prevent the use of event trigger (EVT). The code checks for internal/external commands by testing against command number 100 (internal commands start at 800). The constant 100 was never a great choice but didn't seem so bad when the maximum command number was in the 90s.
A temporary fix is to change a line in the pthScript function in pigpio.c (currently line 6548).
Change if (instr.p[0] < 100) to if (instr.p[0] < PI_CMD_SCRIPT).
When I have time I will tidy up scripts a little by preventing commands which have no useful functions within the script.

The change from "if (instr.p[0] < 100)" to "if (instr.p[0] < PI_CMD_SCRIPT)" will be in V66.


add version switcher dropdown

Fixes #588
Preview: http://stephenplusplus.github.io/gcloud-node-gh-pages-again/#/docs/

Got rid of the History view in favor of a dropdown. The dropdown and last built date are now in the sidebar. Let me know what ya think.

I only see master when I try locally. Any reason why that could be happening?

It's always been that way, because we don't carry the built json for all versions locally. To test, you can:

clone gcloud-node under a different name (gcloud-node-gh-pages)
switch to the gh-pages branch and git checkout -- versions.txt json
switch back to my branch in your normal gcloud-node directory
npm run docs
cp -R docs/* ../gcloud-node-gh-pages

Oooh, I found git checkout -- versions.txt json helped to do last after the cp -R but looks great! :)

Oops :D Thanks!

I noticed that the versions sit low on the page when in mobile mode due to being in the sidebar. This is certainly not ideal for mobile I think, but perhaps changing versions is not as important for mobile? Should we simply hide the version dropdown on mobile?

It might be nice to move it up top in the smaller viewports. I would rather leave it where it is or move it up than remove it completely though.

Can you move it up without moving the whole sidebar to the top?

I’ll try :) I’m thinking a directive in two places, whose visibility toggles via CSS at the appropriate dimensions.

On May 19, 2015, at 5:22 PM, Ryan Seys<EMAIL_ADDRESS>wrote:
Can you move it up without moving the whole sidebar to the top?
—
Reply to this email directly or view it on GitHub https://github.com/GoogleCloudPlatform/gcloud-node/pull/612#issuecomment-103670429.


Use Appium.WebDriver instead of Selenium.WebDriver for tests.

Note sure if this is desired or not, but this allows the Get Element Attribute test in #27 to work. Seems like Selenium.WebDriver tries to execute a script in order to read attributes?

Converting this to a draft as it's not actually needed for #27. Feel free to close if you'd prefer.

Actually, going to close this for now. I've not run into anything else that would require it so far.


I need move a slide from one ppt to another ppt

I've a project and one of the requirements is to move a slide from one presentation to another, but i can't to find a solution and i think to doesn't exists one, i need to do this with this code
prs = Presentation('ppt2.pptx')

for slide in prs.slides:
    for shape in slide.shapes:
        if hasattr(shape, "text"):
            for paragraph in shape.text_frame.paragraphs:
                for run in paragraph.runs:
                    if "Nuestra experiencia en su industria" in run.text:
                        url = "ppt2.pptx"
                        prsIndustria = Presentation(url)
                        slideAn = prsIndustria.slides[0]
                        slide = slideAn

I know that doesn't works like this but its a example. So help me with this please.

I've solved this problem by iterating over the shapes in the source slide, copying them one by one and creating them in the dest slide. It's not an easy approach as you have to do a lot of manual work like copying over styles and contents and things like that, but for my use case it has worked just fine

Do you have a working code snippet by any chance @mszbot please?


Can't connect

I had hubot-hipchat working for months and then about a week ago our bot disconnected. I'm just now getting getting around to debugging. When I try locally to have our bot connect I'm getting the following anonymized output with debug turned on. I'm not sure where to go from here.
$ bin/hubot --adapter hipchat
[Tue Feb 03 2015 13:06:12 GMT-0600 (CST)] DEBUG Loading adapter hipchat
[Tue Feb 03 2015 13:06:12 GMT-0600 (CST)] DEBUG HipChat adapter options: {"jid":"username@chat.hipchat.com","password":"************","token":null,"rooms":"All","host":null,"autojoin":true}
[Tue Feb 03 2015 13:06:12 GMT-0600 (CST)] INFO Connecting HipChat adapter...
[Tue Feb 03 2015 13:06:13 GMT-0600 (CST)] DEBUG  OUT > <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN"><some random hash></auth>

Also, if it helps here is my package.json
{
  "name": "hosted-hubot",
  "version": "2.7.1",
  "private": true,
  "author": "GitHub Inc.",
  "keywords": [
    "github",
    "hubot",
    "campfire",
    "bot"
  ],
  "description": "A simple helpful robot for your Company",
  "licenses": [
    {
      "type": "MIT",
      "url": "https://github.com/github/hubot/raw/master/LICENSE"
    }
  ],
  "repository": {
    "type": "git",
    "url": "https://github.com/github/hubot.git"
  },
  "dependencies": {
    "hubot": ">= 2.6.0 < 3.0.0",
    "hubot-scripts": ">= 2.5.0 < 3.0.0",
    "hubot-hipchat": "~2.6.4"
  },
  "engines": {
    "node": ">= 0.8.x",
    "npm": ">= 1.1.x"
  }
}

I recently had this happen and had stumbled upon this issue report while I was looking into the issue.  It turned out that our bot's password had been changed.  Apparently the XMPP interface just goes dead on authentication failures.  Hope this helps you.

@gmodea that was it

Appears to be resolved.


Add "nextpack" integration setup

Hopefully this'll ease our developing in Next.js
Nextpack is the development sub-repo, allowing us to develop Next.js
features and Turbopack together. This sub-repo will stitch together the
rust crates in Next.js and the crates in Turbo, so they appear as 1
logical Cargo workspace.

There are two steps:

\`\`\`bash
# This will clone next.js into ./next.js
# if you wanted, you can link your own already-checked-out next.js repo.
$ ./scripts/init.cjs
# This read the Cargo.toml from Next.js and Turbo, generating a new
# Cargo.toml workspace in this directory.
$ cargo run --bin sync-workspace
\`\`\`

## FAQs

### Failed to load manifest for workspace member …

You can't have an optional workspace member (or if you can, I can't
figure it out). So the `./next.js/…` crate members are gonna error out
if you try to run a Turbo crate without first cloning next.js.

To fix, run `./scripts/init.js` again. It'll resync your Cargo
workspace.

### Why is `init` written in JS?

See the above. If we wrote it in Rust, any failure in the repo setup
would prevent it from running.

### Why is there a turbo-crates symlink dir?

Cargo cannot contain nested workspaces, and if we used
`../crates/turbopack` as a workspace member, it would error out. By
using a symlink, we avoid the problem.

### How do I run `next dev --turbo` with this?

I'm still working on it.

Cargo.lock is also synced

What does this gain us?

It installs the right version of dependencies. Before it was broken due to selecting the latest version, which e.g. ended up with two versions of swc_core
Also it's more consistent with the actual version used in next, and the conflict output tells us to update next.js or turbo lockfiles.


A broken external pull request

@resin-jenkins ok to test

@resin-jenkins retest this please

@resin-jenkins retest this please

@willnewton guess this test PR can be closed now?


Tilemap should default to the screen size

Like the title says, the tilemap should default to 10x8 (of 16x16 sprites)

Done


⚠ Bofrost.fr has degraded performance

In ec6f748, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1668 ms

Resolved: Bofrost.fr performance has improved in 21459c3.


Added Travis setup and coverage support.

@evgenyz Tests pass on my machine, do you think that it could be a libyaml  0.1 vs 0.2 issue?

Nope, I have rebased and it still fails.

Explanation: https://github.com/crystal-lang/crystal/pull/6287. I'll make a proper fix

Fixed: https://github.com/OpenSCAP/yaml-filter/commit/a103af71ff827671ecfa3c9b7d7959b433a28ffa

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@a103af7). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #3   +/-   ##
=========================================
  Coverage          ?   61.38%
=========================================
  Files             ?        5
  Lines             ?      751
  Branches          ?        0
=========================================
  Hits              ?      461
  Misses            ?      290
  Partials          ?        0

Continue to review full report at Codecov.

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

LGTM. Thank you for assistance!


Update arrow2 version.

Codecov Report

Merging #61 (ac9e178) into main (34daca8) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #61   +/-   ##
=======================================
  Coverage   95.37%   95.37%
=======================================
  Files           8        8
  Lines        1471     1471
=======================================
  Hits         1403     1403
  Misses         68       68

Impacted Files
Coverage Δ

arrow2_convert/src/serialize.rs
100.00% <100.00%> (ø)

arrow2_convert_derive/src/derive_enum.rs
98.52% <100.00%> (ø)

arrow2_convert_derive/src/derive_struct.rs
99.17% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Thanks for the change @teymour-aldridge!


bug: fail to compile app with llamaindex v0.4.0

After upgrading to llamaindex v0.4.0, Next app fails to build with following errors (see full logs here):
./node_modules/llamaindex/dist/ChatHistory.js
Attempted import error: 'tokenizers' is not exported from '@llamaindex/env' (imported as 'tokenizers').
Import trace for requested module:
./node_modules/llamaindex/dist/ChatHistory.js
./node_modules/llamaindex/dist/index.edge.js
./node_modules/llamaindex/dist/index.react-server.js
./app/api/chat/route.ts
./node_modules/llamaindex/dist/PromptHelper.js
Attempted import error: 'tokenizers' is not exported from '@llamaindex/env' (imported as 'tokenizers').
Import trace for requested module:
./node_modules/llamaindex/dist/PromptHelper.js
./node_modules/llamaindex/dist/index.edge.js
./node_modules/llamaindex/dist/index.react-server.js
./app/api/chat/route.ts
./node_modules/llamaindex/dist/TextSplitter.js
Attempted import error: 'tokenizers' is not exported from '@llamaindex/env' (imported as 'tokenizers').
Import trace for requested module:
./node_modules/llamaindex/dist/TextSplitter.js
./node_modules/llamaindex/dist/index.edge.js
./node_modules/llamaindex/dist/index.react-server.js
./app/api/chat/route.ts
./node_modules/llamaindex/dist/embeddings/OpenAIEmbedding.js
Attempted import error: 'Tokenizers' is not exported from '@llamaindex/env' (imported as 'Tokenizers').
...

@marcusschiesser  @himself65  it's because https://www.npmjs.com/package/@llamaindex/env needs to be published

@manekinekko for your dev environment you can npm install /path/to/LlamaIndexTS/packages/llamaindex in the meantime

@parhammmm and @manekinekko great catch! That's the problem if your always using the local packages :D - Sorry about that. Just released v0.4.1 with the @env package included - Please have a try again

Thanks @marcusschiesser. That did indeed fix the origin issue.
However, now I am having other issues with missing (or remaned) types. It's worth mentioning that I am using the Next.js sample built by create-llama package which probably needs to be updated.

try EngineResponse  instead of Response. I'm not sure what AgentStreamChatResponse as it's gone is but ReadableStream<EngineResponse> seems like your best bet

Thank you @parhammmm  and @marcusschiesser !! Our sample app is now building successfully.
@seldo you can try again the app, it should build now 😃

@marcusschiesser can we also republish the @llamaindex/community package with the 0.4.1?


KYLIN-4788 add segmentName and regionName in Coprocessor deadline info

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[x] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[ ] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I will prepare another pr against the document branch
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at user@kylin or dev@kylin by explaining why you chose the solution you did and what alternatives you considered, etc...

Add segmentName and regionName to Coprocessor deadline exception info,for locating the cube and region exactly。
When Coprocessor throws dealline expcetion，the info will looks like this：

Pull Request Test Coverage Report for Build 6456

13 of 152 (8.55%)  changed or added relevant lines in 3 files are covered.
16 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.04%) to 28.01%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

storage-hbase/src/main/java/org/apache/kylin/storage/hbase/cube/v2/CubeHBaseEndpointRPC.java
0
1
0.0%

storage-hbase/src/main/java/org/apache/kylin/storage/hbase/cube/v2/coprocessor/endpoint/CubeVisitService.java
2
4
50.0%

storage-hbase/src/main/java/org/apache/kylin/storage/hbase/cube/v2/coprocessor/endpoint/generated/CubeVisitProtos.java
11
147
7.48%

Files with Coverage Reduction
New Missed Lines
%

stream-core/src/main/java/org/apache/kylin/stream/core/storage/columnar/ColumnarStoreCache.java
1
56.82%

stream-core/src/main/java/org/apache/kylin/stream/core/storage/CheckPointStore.java
2
73.74%

tool/src/main/java/org/apache/kylin/tool/query/ProbabilityGenerator.java
3
76.32%

core-metrics/src/main/java/org/apache/kylin/metrics/lib/impl/MetricsSystem.java
5
66.67%

storage-hbase/src/main/java/org/apache/kylin/storage/hbase/cube/v2/coprocessor/endpoint/generated/CubeVisitProtos.java
5
18.16%

Totals

Change from base Build 6452:
-0.04%

Covered Lines:
26259

Relevant Lines:
93749

💛  - Coveralls

good job，+1 @xiaowangyu

Thank you for @fengpod 's patch and @bigxiaochu 's comment, I will verify and merge this patch.

Hi @fengpod , we know that apache project provide a version convention of MAJOR.MINOR.PATCH, and this patch require user to manually upgrade coprocessor, we think it is suitable for release in next MINOR or MAJOR version.
We suggest to move release of this patch into next minor version (3.2.0), so we won't merge it right now.


Knight_Post

Your checklist for this pull request
Author name
Author: Aditya PV
About your game
In "Knight Post," you step into the armor of Sir Mailus Postus, the valiant knight postman of the kingdom. Your noble duty is to ensure that every piece of mail reaches its destination safely. As Sir Mailus Postus, you'll face challenges and puzzles to deliver all the mail to complete your quest.
** Control Sir Mailus Postus using W, A, S, and D keys (Use j to reset level). Your mission is to push the mail to the doormat. Move the pushable bookshelves strategically to clear the path for delivery. Complete levels by delivering all the mail. Conquer challenges in this medieval postman adventure.**
Code
Check off the items that are true.

[ x] The game was made using the Sprig editor.
[x ] The game is placed in the in the /games directory.
[x ] The code is significantly different from all other games in the Sprig gallery (except for games labeled "demo").
[x ] The game runs without errors.
[ x] The name of the file/game contains only alphanumeric characters, -s, or _s.
[ x] The game name is not the same as the others from gallery

Image (If an image is used)

[ x] The image is in the /games/img directory.
[x ] The name of the image matches the name of your file.

Thanks for your PR!

Awesome game, really beautiful! Where did you hear about Sprig?

I had found out about Sprig and Hack Club while applying for Thiel Fellowship.

Nice! Just one thing, the image need to be a real "photo" of your game:)

Nice! Just one thing, the image need to be a real "photo" of your game:)

Changed the pic 😃


Revisit DataServiceSpec tests and add checks for server state after certain operations

Just generally try and tackle as many dangling TODOs as possible

Have you been able to reproduce the compile issue locally? It'd be good to get that solved. Other than that and my minor comment, :+1:

@wemrysi It's weird because the Mongo 2.6 Travis build seems to consistently encounter a compiler crash (which is probably not due to doc as the doc command succeeds locally). This time around the failure for the build of Mongo 3.0 was probably caused by two unrelated tests having the same hardcoded port number. I fixed that so hopefully that should disappear.
Really unclear about what the compiler crash is about though, and furthermore perplexed as to why it only happens with the build for Mongo 2.6. What are the differences between the two builds, do they both test core? Because if so, that sounds like a bit of a waste but if one of them does not, then maybe sbt is getting into a weird state for some reason and that is causing the compiler crash.

That build does a bit more than the other two just because it happens to be the first job. The first job builds the docs, does a coverage run and runs the jar test, whereas jobs 2, 3, ..., N just run the tests. Yes, all the tests are run for all environments, but the non-it tests run so fast that it doesn't really matter and the build doesn't complete until all jobs have completed, so not running them on the other jobs isn't really going to speed up the overall build time.

hmm. Do we build the docs for the tests on Travis? because I just ran test:doc and that comes up with a few failures so that could explain the crash I guess.

But the things it's complaining about are also in master, so unlikely to be the culprit.

Well, at least seems to have fixed the issue with the 3.0 build.
@wemrysi Unless you have some ideas for possible solutions to the first build failure, I am inclined to merge and figure out what is up with that failure later.

No, we don't run test:doc on travis. Have you tried running the same command that is run on travis locally to see if you can reproduce?

nope, let me try that (duh...)

@wemrysi Okay, ran the build script on my local machine and was able to reproduce. It appears that we are running into a scoverage issue. Compiling core without coverage works fine, but with coverage, it crashes almost immediately. It appears the file triggering the crash is QueryFile.scala.
Not sure what to do about this, I can submit a crash report on the scoverage project github but what do we do in quasar, disable coverage for that branch? I can also have a look at QueryFile.scala and see if I might not be able to refactor some things in hopes that that would magically aligns the bits in the right order and we would sidestep the crash...

Looking at the diff with master, no change in QueryFile.scala pops up as a possible culprit.

From the error message, it looks like it involves line 196 in QueryFile.scala, which is in this function
private def firstFile(lp: Fix[LogicalPlan]): Option[AFile] =
  Tag.unwrap(lp foldMap[FirstOption[QPath]] {
    case Fix(LogicalPlan.ReadF(p)) => Tag(Some(p))
    case _                         => Tag(None)
  }) flatMap pathToAbsFile

@wemrysi Ya, it looks like it does not like the TypeApply so presumably it's not a huge fan of scalaz.Tag. If I change the implementation to this: lp.collect{case Fix(LogicalPlan.ReadF(p)) => p}.headOption.flatMap(pathToAbsFile) then it does not trigger the compilation crash. Even though it is fewer characters, I am not a huge fan of this alternative implementation because it builds up the whole list of paths as opposed to simply picking the first one, but I guess it's a reasonable compromise in order for coverage to work. I will comment out the current implementation and write a comment explaining why it can't be used right now and create an issue on scoverage explaining the issue.

Out of curiousity, did you try specifying the types in Tag.unwrap and Tag explicitly, rather than having them inferred? Or maybe even ascribing Option[QPath] as the type of Tag.unwrap(...)?

Just tried all those things, and I still get the crash.

Boo, thanks for trying. If this build succeeds, then :+1:

Well now it's that other server restart failure for which we have a sub-task. Weird that it seems to consistently trigger on the 2.6 branch but not on the other. You said that we were running tests for the web project on both builds right? Anyway, I say we merge this for now and revisit that later.

:+1:

Oops, meant to flatten out those commits first. Oh well. I guess we will have to flatten out the free branch before merging in master anyway, so not a huge deal.