[Resolved] Why Subscribe to something that is not in the database

help
1

I subscribed and published as follows.
But one of the database documents is repeated in the subscription, while it has no _id and is not in the database !

this is publish :

import { Meteor } from "meteor/meteor";
import {Article}  from "../../Collections/Article/Article";
Meteor.publish('Pages.Articles', function() {
    return Article.find({});
});

this is Subscribe :


// Subscribe Data
 const ArticlesContainer = withTracker(() => {
        const handle = Meteor.subscribe('Pages.Articles');
        const loading = handle.ready();
        if(loading){
            const data =  ArticleCollection.find({}, { sort: { createdAt: -1 } }).fetch() ;
            return {
                data ,
                loading
            };
        }
        
})(Articles);

// For Redux
const MapStateToProps = state => {
    return {
        HasUser : state.HasUser
    }
}

// Connect To Reducer
export default connect(MapStateToProps)(ArticlesContainer);

And i handle the Data as Follow :


 { this.props.data
        ?  
        this.props.data.map((article , index) => <Article key={index} title={article.title} img={article.img} />
          : 
            ''          
 }
2

For example, I have 1 articles in the database, but it Subscribe 2 records, one of which is a duplicate of the other, except that it does not have an _id
like this :

image

3

I filtered documents that did not have IDs and stopped rendering them, but I do not really know why something that is not in the database is shared?

Everything Welcome

4

This will not work. You assigned the result of .ready() to loading which inverts the logic.

Fix that, and then get rid of the if conditional, you don’t need it.

3 Likes
5

@captainn
How exactly do you think it should be implemented?

6

I modified the code, but like before, it Subscribe what is not in the database

image

image

7

Do you have any kind of offline support running there? What does your Collections/Article/Article.js file look like?

That second document looks like a copy of the first, with the _id prop stripped off. I’m not sure what’s going on there.

2 Likes
8

First, it is true that only one of the documents in the database is duplicated.
Except it does not have _id

Second, because it does not have a duplicate _id document, I prevented it from rendering.

And my Article.js file looks like this :

image

9

@captainn
In fact, I made the _id and slug fields mandatory to render the article .

10

And this is Article Collection File :

image

11

Those allow functions should all be returning false, not true,or replace allow with deny. The way it is now, anyone can can update, insert or delete any document in your collection.

This is a weird problem, I don’t know where that phantom document is coming from.

1 Like
12

@captainn Is my publish correct?

image

13

@filipenevola This problem exists precisely for user publishing as well .

image
image791×101 11 KB

As you can see, the second document is exactly the copy of the first document, except it has no id

In this publish , I did not interfere and this user publish is Logged in

14

Everything looks correct here - have you removed autopublish and insecure packages?

1 Like
15

this is my Packages :

image

I think both packages are comments

16

I wonder if it could be staringatlights:fast-render doing it - try disabling that (and ssr) and see what happens.

1 Like
17

@captainn
Exactly when I do these two things, the system works properly and only the documents in the database are Subscribe.

18

But I need ssr, I also need server side subscription.

@abecks Is this bug from the staringatlights:fast-render package?

19

If the problem disappears when you remove that plugin, it’s probably a bug in there, or a configuration problem with that package. I’d check with them about it.

1 Like
20

@captainn
Thanks for following up, please finally announce the result