CAN NOT UPDATE USERINFO IN METACPAN

[snmpd]

is_pause_custodial_account: Reference bless( do{(my $o = 0)}, 'JSON::PP::Boolean' ) did not pass type constraint "Bool"

[oalders]

More context required.

[haarg]

This message appears at the top of the page when attempting to update your profile on MetaCPAN.

[zoffixznet]

Having same issues:

Possibly unrelated steps I took before I encountered the issue:

1. Login to account using GitHub
2. Confirm PAUSE account so that I could edit profile details (worth noting, confirmation link in the email just redirected to metacpan homepage and did nothing to confirm the account; clicking it the second time lead to a page showing an empty JSON object, but this time confirmation worked)
3. Go to https://metacpan.org/account/profile
4. Remove a bunch of sites from "Profiles" section
5. Try to save
6. Get error that ASCII name field is required (it was blank; also this lost all of the attempted changes to Profiles section, so they're back where they were)
7. Enter the ASCII name and save
8. Get confirmation that save has been successful(!)

Now steps directly reproducing the problem:

1. Go to https://metacpan.org/account/profile
2. Click "Save"
3. Error is_pause_custodial_account: Reference bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) did not pass type constraint "Bool" is shown

I tried disconnecting and reconnecting PAUSE account but that didn't help the error (though this time, confirmation email link lead to a full JSON object the first try just fine))

[stigtsp]

I'm having the same problem trying to update my MetaCPAN profile.

    is_pause_custodial_account: Reference bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) did not pass type constraint "Bool"

[oalders]

I think that error is being returned from the API. https://github.com/metacpan/metacpan-api/blob/master/lib/MetaCPAN/Script/Mapping/CPAN/Author.pm#L50-L52

It looks like that's the only place we use boolean in that mapping. @mickeyn thoughts on this? Do we need to fix the data that's being sent from metacpan-web?

[oalders]

This issue was opened 2 days after this merge: https://github.com/metacpan/metacpan-api/pull/1058

Maybe it's related to an updated dep, like Type::Tiny?

[mickeyn]

I'm a bit lost on all the different Type::Tiny versions and it seems we're using an old one. is there a reason for that?

[oalders]

We can't auto-upgrade the deps on the API because some unknown module breaks the test suite if we just upgrade everything to the latest version. I can put in a PR to upgrade Type::Tiny and we could see if this error just goes away. That might be a good way to start.

Having said that, I see that the CircleCI build is no longer running on automated API pull requests to upgrade deps. I think it's because those are created by the bot user.

[karenetheridge]

We can't auto-upgrade the deps on the API...

What is the breakage? is there a ticket on this for folks to poke at?

[oalders]

What is the breakage? is there a ticket on this for folks to poke at?

I just ran a job since CircleCI hasn't been doing it automatically. It looks like some Pod parsing changed. That's my best guess. It could have been years ago, though, since the deps are very badly out of date.

https://app.circleci.com/pipelines/github/metacpan/metacpan-api/183/workflows/dd0c1872-d397-459d-bb41-5cf122023977/jobs/192

[oalders]

If this isn't fixed in about 90 minutes, we should re-open this ticket.

[oalders]

Re-opening. 😭

[nrdvana]

Happens for me too:

is_pause_custodial_account: Reference bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) did not pass type constraint "Bool"

A quick test reveals that Types::Standard Bool simply doesn't recognize JSON::PP booleans:

perl -MTypes::Standard=:all -MJSON::PP -E 'my $j= decode_json("[false]"); say Bool->check($j->[0])'

I think the easiest way to fix it would be define a broader BoolMaybeJson type and declare that for the attribute wherever this validation is occurring. Or, find the JSON decode wherever this is getting checked and have it decode booleans as scalars instead of objects.

I'm not finding either of these in the code... there seems to be a lot of clever abstraction involved. If someone gives me some pointers, I could contribute a patch.

[bombsimon]

I don't really have any new information to give but just wanted to say I have the same issue. I used to be affected by #2192 for a long time but today the suggested solution finally worked by disconnecting all my accounts and signing in from scratch (yay)! First thing I tried to go and update my profile but get the error message noted above:

is_pause_custodial_account: Reference bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) did not pass type constraint "Bool"

If there's anything I can test or provide to help figure this out let me know!

Windows 11 22H Google Chrome Version 106.0.5249.119 (Official Build) (64-bit)

[oalders]

I think it may be related to this problem I had to work around in perlimports:

        # The Bool type provided by Types::Standard doesn't seem to like
        # JSON::PP::Boolean
        for my $key ( keys %config ) {
            my $maybe_bool = $config{$key};
            my $ref        = ref $maybe_bool;
            next unless $ref;
 
            if (   $ref eq 'JSON::PP::Boolean'
                || $ref eq 'Types::Serializer::Boolean' ) {
                $config{$key} = $$maybe_bool ? 1 : 0;
            }
        }

[oalders]

@tobyink did I understand that problem correctly? ^^

[tobyink]

The Bool type is defined by Moose as allowing undef, the empty string, 0, or 1.

Although it's undocumented, it silently allows overloaded objects too, but uses their stringification instead of their boolification!

Mouse in PP mode acts like Moose is documented to act. Mouse in XS mode accepts overloaded objects, but only if they boolify to false. If they boolify to true, they throw a type constraint error.

Basically it's a mess.

As an attempt to be consistent and sane, Types::Standard::Bool accepts the four values documented by Moose and nothing else. It does have a coercion defined though, which accepts ANY value and does !! to it.

[oalders]

I think the JSON serializer is being chosen here:

https://metacpan.org/release/DRTECH/Search-Elasticsearch-2.03/source/lib/Search/Elasticsearch/Serializer/JSON.pm

We have a very old version of JSON::MaybeXS.

carton show JSON::MaybeXS
JSON-MaybeXS-1.003009

I think maybe we could try upgrading that dep and seeing if there's any improvement. At the very least we may see a slight speed boost since it looks like we're not actually using XS to serialize JSON here.

[nrdvana]

It's as simple as this:

use 5.036;
my $json_mod= $ARGV[0];

package Test {
  use Moose;
  use Types::Standard qw( Bool );
  has field => ( is => 'rw', isa => Bool, coerce => $ARGV[1] );
}

eval "require $json_mod" or die $@;
eval { Test->new({ field => $json_mod->new->decode("[true]") })->[0] };
say "true: $@";
eval { Test->new({ field => $json_mod->new->decode("[false]") })->[0] };
say "false: $@";

These all fail: (no coercion)

perl test.pl JSON
perl test.pl Cpanel::JSON::XS
perl test.pl JSON::XS
perl test.pl JSON::MaybeXS

These all pass: (coercion)

perl test.pl JSON 1
perl test.pl Cpanel::JSON::XS 1
perl test.pl JSON::XS 1
perl test.pl JSON::MaybeXS 1

I would happily contribute a patch to turn on coercion except I can't even find where these Moose classes are coming from. The string is_pause_custodial_account doesn't even occur in this repo. Where is it coming from? What automagic cleverness is generating these class definitions? That's where the change needs to be, because Type::Tiny's concept of a boolean is not compatible with JSON's concept of a boolean, and the code needs updated to deal with that.

[oalders]

You'd need to start in metacpan-api.

[oalders]

Closed via https://github.com/metacpan/metacpan-api/pull/1069