FactoryGirl.create issues "LocalJumpError: no block given (yield)" with Rails 5 - factory-bot

I'm in the process of upgrading my app to Rails 5
When running the tests with rails 5 enabled I started to get "LocalJumpError: no block given (yield)" on several object creation sentences like this one:
let!(:entity) { create(:entity) }
This started to happen after I upgraded to Rails 5.0.0
I tried using build instead of create on that line and the error doesn't show up in that case.
Has anyone got a similar issue?
My Entity factory is this one:
FactoryGirl.define do
factory :entity do
entity_type 'A'
account { create(:account) }
ilk []
after(:build) do |entity|
entity.names << build(:name)
entity.addresses << build(:address)
end
trait :incomplete do
incomplete true
end
end
My Gemfile looks like this: https://jpst.it/Lb6N
EDIT
I found out the issue is not with FactoryGirl but with Mongoid gem. I opened a ticket on JIRA for that project. Here's the link but you'll need to have an account with access to Mongoid project at JIRA: https://jira.mongodb.org/browse/MONGOID-4302
The details of this ticket are that by running rspec -b to see the trace, I identified the issue on this line on the mongoid gem:
https://github.com/mongodb/mongoid/blob/master/lib/mongoid/clients/options.rb#L25
The issue disappears if I replace that line (yield self) with just:
self
I'm not sure however if this is a feasible fix, so I opened the ticket mentioned before to get mongoid's feedback and see what can be done.
I'll update again when I get any feedback.

After a lot of debugging I found the source of the issue on a local fork of the mongoid_token gem, which was causing this weird problem. Mongoid and FactoryGirl gems are not related to this issue, neither the original mongoid-token gem.

Related

Magento 2.4: Unable to apply data patch Magento\CatalogRuleSampleData\Setup\Patch\Data\InstallCatalogRuleSampleData

Getting the below error while trying to install sample data and upgrading the setup in Magento 2.4.2-p1
Error: Unable to apply data patch Magento\CatalogRuleSampleData\Setup\Patch\Data\InstallCatalogRuleSampleData for module Magento_CatalogRuleSampleData. Original exception message: Rolled back transaction has not been completed correctly.
Please help.
Syntax error(s) are existed in the following sample csv files.
/vendor/magento/module-catalog-rule-sample-data/fixtures/catalog_rules.csv
/vendor/magento/module-sales-rule-sample-data/fixtures/sales_rules.csv
2 solutions for the above issue:
Fix and validate the above CSVs manually or online tool like https://csvlint.io/
Comment line of code, calling above CSVs
\Magento\CatalogRuleSampleData\Setup\Installer.php
\Magento\SalesRuleSampleData\Setup\Installer.php
like:
/**
* {#inheritdoc}
*/
public function install()
{
//$this->rule->install(['Magento_CatalogRuleSampleData::fixtures/catalog_rules.csv']);
}
I also received the same error and invested four days rectifying it.
I also tried the above solution, i.e., commenting the line under install function from catalogue rule sample data and sales rule sample data. It too worked, but only temporarily. Because after following the above procedure, you cannot see the products from your Magento homepage, just banners only visible to you.
The real problem is that there is no sufficient space to deploy the sample data. Clear more than 4GB of space on your system and try it. It will work.
You need to set correct permissions for var/ pub/ & generated/ directories
after above, your error will be vanished on setup:upgrade
I had such a problem and recovered by running the command:
php bin/magento sampledata:remove
After upgrading, just run normally.

How can I set grafana 7 to work with warp10 2.7.x?

I've just install a fresh warp10 standalone server version 2.7.2.
Using beamium to send data into it and seeing the data via the VScode plugin is OK and I can see graph in GTS preview.
I've also installed a fresh grafana and warp10-plugin following the warp10 recommandation on the ovh github.
When execution a default warp10 query (via editor), grafana add some strings in the query, like the start or end value, so in the end the query look like:
1609947849757000 'start' STORE
'2021-01-06T15:44:09.757Z' 'startISO' STORE
1610034249757000 'end' STORE
'2021-01-07T15:44:09.757Z' 'endISO' STORE
86400000000 'interval' STORE
199538106 '__interval' STORE
199538 '__interval_ms' STORE
[ 'host.local.domain' ] 'host_list' STORE
But when executing, there is an error poping in the warp10 logs, after decryption it tell:
Exception at '=>1609947849757000<= 'start' STORE '2021-01-06T15:44:09.757Z'' in section [TOP]
It seems that it don't take the LONG (DOUBLE?) number for what it is, and try to match a function with the same name that don't exists.
On grafana side, I don't have any valuable help, it tell me:
WarpScript Failure on Line -1, Unable to read x-warp10-error-line and x-warp10-error-line headers in server answer
Do I miss something ?
==== Edit: 2021-01-07 17:32 UTC
After first reply, doing other test:
I've tryied the same query, and the error is still the same.
Warpscript failure
But in VScode this query works:
{
'token' $RTOKEN
'class' '~.*'
'labels' {}
'end' '2021-01-07T17:35:28.086Z'
'timespan' 21600000000
} FETCH
I've also try to use the bartender stuff in grafana and it work fine too...
So everything should work, I must miss the obvious.
Can Java version have an impact ?
If the datasource is working, you didn't miss anything.
Do you use the built in warpscript editor ? Make sure you ticked the "WarpScript Editor" checkbox:
Then, do the simplest FETCH request you can do, or copy paste the code you did in VSCode.
You can define your own variables too in the datasource configuration. It is usefull for tokens.
I just setup Grafana 7.3.6 + ovh plugin to check, it seems there is no regression issue.
The full WarpScript can be found in the browser console.
The header error is linked to Grafana 7, no problem with Grafana 6.x. Install Grafana 6.x if you want WarpSript detailed errors.
Edit: Issue is now fixed and merged into ovh github master.
If you want to test another Warp 10 data source, you can use the credential and advices in this article. You just need to go before covid lockdown to find relevant office beertender data...

getting can't validate error (13) for mlab for heroku

I'm trying to connect to a mongoDB instance hosted by mlab from heroku but It just keeps responding with:
`validate!': not authorized for query on .lotto_results (13)'
Which doesn't make sense as the user account has dbOwner role which means it should be able to read and write.
I found somthing about how heroku's nature (how it restarts) can cause problems but It didn't seem to explain how to fix it ( I would like to give a link to this but I can't seem to find the web page, it was a google thread I think).
I'm using the mongoid gem, with sinatra and grape and sprockets for assets (if that helps).
Not sure what else to mention, if there's anything else just ask and I'll try to answer it.
In the end I solved the problem by changing my config to:
development:
clients:
default:
uri: <%= ENV['MONGOLAB_URI'] %>
which used the pre-generated uri and it suddenly started working, well kind of, I'm still having issues but it's not an authentication issue at least.

proget Failed to process request. 'There was an error processing the request: Invalid API key.'

I recently setup Proget to try its nuget and chocolatey servers. Now when I try to publish packages to nuget feed through a teamcity build, I keep on getting error "proget Failed to process request. 'There was an error processing the request: Invalid API key.'.". I've made 100% sure that the name and password are working fine and specified API key as per Proget doco (i.e. username:password ) . THat feed already has one package which I published on the day I installed Proget for trying out. What could have gone wrong?
I found a work around.
[1] I confirmed that my username:password combination is correct.
[2] Then I renamed that original feed to feed_old (or whatever you
want or even delete it if it doesn't have anything important in it) I
had created for trying out and which wasn't allowing publishing
through teamcity and giving the error message as per the question's
message.
[3] Created new feed with the name I wanted.
[4] Confirmed that the username I was using in API key had necessary
privileges to publish to this new feed I just created.
[5] Then tested the publishing to this feed through teamcity and
VOILA!! it worked.
I don't know why this happened in the first place though. It would be good to find out and be able to fix underlying reason rather than using the above mentioned workaround.

WARN org.springframework.web.servlet.PageNotFound - Request method 'POST' not supported

Os is Mac Os Maverick.
In a jhipster context (last version, 1.2.2), I get an error when I request the default application on an entity I have just generate using yo jhipster:entity generator.
I run a yo jhipster to create a vanilla application with mongodb as database, java 7 and nothing special.
Then I run grunt build and grunt server for hot reload on the client part and mvn spring-boot:run for the server side app.
When I go to the http://localhost:8080/ url, I get the normal page. I can sign in with either the user or admin login.
I run the yo jhipster:entity foo to get an exemple of rest service in the back end.
When I request for the foo resource with the URL http://localhost:8080/#/foo, I get the page to CRUD the resource as it is said on the jhipster website.
But when I try to create a foo item with the modal form, I get an error on the back end server log ([WARN] org.springframework.web.servlet.PageNotFound - Request method 'POST' not supported).
I can't figure out how to solve this.
Do I miss something in the documentation ?
Do you have any idea, hint ?
I have the same issue using H2 as development database instead of mongodb.
Thanks.
Hervé
This might be due to MongoDB, if you have a date field.
We will release very soon a new and improved Entity sub-generator, which should work better for you. While testing it, I had a serialization issue with MongoDB and a date field, and I corrected it in this new version. This is due to Jackson which can't serialize Joda Time dates (the correct annotations were only generated for SQL databases, not NoSQL databases)