Snowplow Inspector, debugger for Chrome, now validates schemas

#1

Jethro has been hard at work improving the debugger. First he ported it to Typescript for better maintainability, then he reworked the design to be more readable and useful. Following that he’s added a really useful new feature.

You can now validate schemas from inside the debugger. It’s really quite awesome!

More info
Install the extension

We’d love to hear your feedback! For feature requests and bugs, create an issue.

7 Likes

#2

I can only add, that CORS are crucial to have access to own IGLU repo.

BTW: In issue #7 i have asked to add variable type display. I saw it has been added, merged and issue is closed. Will this functionality be added in next release?

0 Likes

#3

Good point, CORS is important to make this work.

On the variable type, it’s available as a hover state on the variable itself. Couple of examples:

image
image

1 Like

#4

@shermozle,

Yes, yes - I have seen tooltips.

Once again thanks for JSON validation - this would make our QA happy and save lots of dev hours to fix missed issues…

0 Likes

#5

Great new feature, thanks so much for the efforts!

0 Likes

#6

I’m curious… if I register my own s3 static web iglu repository, does the status on my self describing event supposed to change from unrecognised to valid (assuming my schema checks out)?

Because I’m still getting unrecognised for my self-describing event.

It’s showing hover message: “at least one repository shows CORS error”.

I’ve configured my S3 to allow all origin and headers for testing purpose. But I still get the CORS error message when hover the unrecognised label.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Thanks.

0 Likes

#7

It should work, yeah. We’ve mostly had success with the following S3 Policy:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
</CORSRule>
</CORSConfiguration>

But specifying the MaxAgeSeconds like you have shouldn’t really make much difference. After that, if it’s still getting CORS errors then it’s usually Chrome helpfully caching the old CORS status. Clearing your browser cache and trying again usually fixes that.

0 Likes

#8

Thanks jethron, clearing browser cache is the solution :slight_smile:

0 Likes