Calling methods on a ComponentAddress stored in a badge does not work

[beemdvp]

Small reproduction of a bug I encountered. Currently I store ComponentAddresses in NFTs and then later call a read method based on the component address. Below is a small reproduction of the bug:

use scrypto::prelude::*;

blueprint! {
    struct Caller {
        sample_vault: Vault
    }

    impl Caller {
        pub fn get_comp_state(bucket: Bucket) {
            borrow_component!(bucket.non_fungible::<Badge>().data().component).call::<()>("get_state", args!());
        }
    }
}

#[derive(NonFungibleData)]
struct Badge {
    component: ComponentAddress
}

blueprint! {
    struct Hello {
        sample_vault: Vault,
        resource: ResourceAddress
    }

    impl Hello {
        pub fn instantiate_hello() -> ComponentAddress {
            let my_bucket = ResourceBuilder::new_non_fungible()
                .metadata("name", "HelloToken")
                .metadata("symbol", "HT")
                .mintable(rule!(allow_all), Mutability::LOCKED)
                .no_initial_supply();

            Self {
                resource: my_bucket,
                sample_vault: Vault::new(my_bucket),

            }
            .instantiate()
            .globalize()
        }

        pub fn get_state(&self) {

        }

        pub fn get_badge(&self) -> Bucket {
            borrow_resource_manager!(self.resource).mint_non_fungible(&NonFungibleId::random(), Badge { component: Runtime::actor().as_component().0 })
        }
    }
}

resim new-account
resim publish .
resim call-function $packageAddress Hello instantiate_hello
resim call-method $helloComponent get_badge
resim call-function $packageAddress Caller get_comp_state 1,$resource

Error message:

Transaction Status: COMMITTED FAILURE: KernelError(SubstateReadSubstateNotFound(ComponentInfo(component_sim1qtu7h9xtg8ac0t58h4auf70hcgldprnnt5ga23pc7vwsx6vqp9)))
Transaction Fee: 0.864329 XRD burned, 0.04321645 XRD tipped to validators
Cost Units: 4294967295 limit, 864329 consumed, 0.000001 XRD per cost unit
Logs: 0
Instructions:
├─ CallMethod { component_address: system_sim1qsqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqs9fh54n, method_name: "lock_fee", call_data: Struct(Decimal("100")) }
├─ CallMethod { component_address: account_sim1qddelpur4cjk34pw37htlxrl80lmrxuvtmpqmf65klwsm24m70, method_name: "withdraw_by_amount", call_data: Struct(Decimal("1"), ResourceAddress("resource_sim1qzjc0sjsx44xm0gag7rmes4tqsfefq5wl5d7quf60ysssv82pq")) }
├─ TakeFromWorktopByAmount { amount: 1, resource_address: resource_sim1qzjc0sjsx44xm0gag7rmes4tqsfefq5wl5d7quf60ysssv82pq }
├─ CallFunction { package_address: package_sim1q8pfeqgqyaxlhnmx00kd2rzh95yl22j9ckmdg8agj68qml37z9, blueprint_name: "Caller", method_name: "get_comp_state", args: Struct(Bucket(512u32)) }
└─ CallMethodWithAllResources { component_address: account_sim1qddelpur4cjk34pw37htlxrl80lmrxuvtmpqmf65klwsm24m70, method: "deposit_batch" }
New Entities: 0
➜  global-pkg git:(master) ✗ resim show component_sim1qtu7h9xtg8ac0t58h4auf70hcgldprnnt5ga23pc7vwsx6vqp9
Component: component_sim1qtu7h9xtg8ac0t58h4auf70hcgldprnnt5ga23pc7vwsx6vqp9
Blueprint: { package_address: package_sim1q8pfeqgqyaxlhnmx00kd2rzh95yl22j9ckmdg8agj68qml37z9, blueprint_name: "Hello" }
Authorization
State: Struct(Vault("b9aabad10ad1e4505ccc4943d40d47f85e349d16ceb25724d75b20968d97897f01040000"), ResourceAddress("resource_sim1qzjc0sjsx44xm0gag7rmes4tqsfefq5wl5d7quf60ysssv82pq"))
Resources:
└─ { amount: 0, resource address: resource_sim1qzjc0sjsx44xm0gag7rmes4tqsfefq5wl5d7quf60ysssv82pq, name: "HelloToken", symbol: "HT" }

[unghuuduc]

Please address the issue, I also got into same problem.

[0xOmarA]

Hey @unghuuduc and @beemdvp. This issue is caused by a change made in v0.5.0 relating to how component addresses work underneath the hood. We are aware of what is causing this issue and this is on our list of items to fix, however, I can not tell exactly when this issue will be fixed.

[backyard-coder]

I believe the problem also affects component addresses stored in the global metadata of a resource. Can anyone confirm this?

[russellharvey]

Fixed.